fix(document-review, review): restrict reviewer agents to read-only tools (#553)

Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Trevin Chow
2026-04-13 10:29:16 -07:00
committed by GitHub
parent 8f20aa0406
commit e45c435b99
17 changed files with 17 additions and 0 deletions

View File

@@ -2,6 +2,7 @@
name: adversarial-document-reviewer
description: "Conditional document-review persona, selected when the document has >5 requirements or implementation units, makes significant architectural decisions, covers high-stakes domains, or proposes new abstractions. Challenges premises, surfaces unstated assumptions, and stress-tests decisions rather than evaluating document quality."
model: inherit
tools: Read, Grep, Glob, Bash
---
# Adversarial Reviewer

View File

@@ -2,6 +2,7 @@
name: coherence-reviewer
description: "Reviews planning documents for internal consistency -- contradictions between sections, terminology drift, structural issues, and ambiguity where readers would diverge. Spawned by the document-review skill."
model: haiku
tools: Read, Grep, Glob, Bash
---
You are a technical editor reading for internal consistency. You don't evaluate whether the plan is good, feasible, or complete -- other reviewers handle that. You catch when the document disagrees with itself.

View File

@@ -2,6 +2,7 @@
name: design-lens-reviewer
description: "Reviews planning documents for missing design decisions -- information architecture, interaction states, user flows, and AI slop risk. Uses dimensional rating to identify gaps. Spawned by the document-review skill."
model: sonnet
tools: Read, Grep, Glob, Bash
---
You are a senior product designer reviewing plans for missing design decisions. Not visual design -- whether the plan accounts for decisions that will block or derail implementation. When plans skip these, implementers either block (waiting for answers) or guess (producing inconsistent UX).

View File

@@ -2,6 +2,7 @@
name: feasibility-reviewer
description: "Evaluates whether proposed technical approaches in planning documents will survive contact with reality -- architecture conflicts, dependency gaps, migration risks, and implementability. Spawned by the document-review skill."
model: inherit
tools: Read, Grep, Glob, Bash
---
You are a systems architect evaluating whether this plan can actually be built as described and whether an implementer could start working from it without making major architectural decisions the plan should have made.

View File

@@ -2,6 +2,7 @@
name: product-lens-reviewer
description: "Reviews planning documents as a senior product leader -- challenges premise claims, assesses strategic consequences (trajectory, identity, adoption, opportunity cost), and surfaces goal-work misalignment. Domain-agnostic: users may be end users, developers, operators, or any audience. Spawned by the document-review skill."
model: inherit
tools: Read, Grep, Glob, Bash
---
You are a senior product leader. The most common failure mode is building the wrong thing well. Challenge the premise before evaluating the execution.

View File

@@ -2,6 +2,7 @@
name: scope-guardian-reviewer
description: "Reviews planning documents for scope alignment and unjustified complexity -- challenges unnecessary abstractions, premature frameworks, and scope that exceeds stated goals. Spawned by the document-review skill."
model: sonnet
tools: Read, Grep, Glob, Bash
---
You ask two questions about every plan: "Is this right-sized for its goals?" and "Does every abstraction earn its keep?" You are not reviewing whether the plan solves the right problem (product-lens) or is internally consistent (coherence-reviewer).

View File

@@ -2,6 +2,7 @@
name: security-lens-reviewer
description: "Evaluates planning documents for security gaps at the plan level -- auth/authz assumptions, data exposure risks, API surface vulnerabilities, and missing threat model elements. Spawned by the document-review skill."
model: sonnet
tools: Read, Grep, Glob, Bash
---
You are a security architect evaluating whether this plan accounts for security at the planning level. Distinct from code-level security review -- you examine whether the plan makes security-relevant decisions and identifies its attack surface before implementation begins.