Menu
Review requirements or plan documents using parallel persona agents that surface role-specific issues. Use when a requirements document or plan document exists and the user wants to improve it.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Researches and synthesizes external best practices, documentation, and examples for any technology or framework. Use when you need industry standards, community conventions, or implementation guidance.
Explore requirements and approaches through collaborative dialogue before writing a right-sized requirements document and planning implementation. Use for feature ideas, problem framing, when the user says 'let's brainstorm', or when they want to think through options before deciding what to build. Also use when a user describes a vague or ambitious feature request, asks 'what should we build', 'help me think through X', presents a problem with multiple valid solutions, or seems unsure about scope or direction — even if they don't explicitly ask to brainstorm.
Refresh stale or drifting learnings and pattern docs in docs/solutions/ by reviewing, updating, consolidating, replacing, or deleting them against the current codebase. Use after refactors, migrations, dependency upgrades, or when a retrieved learning feels outdated or wrong. Also use when reviewing docs/solutions/ for accuracy, when a recently solved problem contradicts an existing learning, when pattern docs no longer reflect current code, or when multiple docs seem to cover the same topic and might benefit from consolidation.
Document a recently solved problem to compound your team's knowledge
Systematically find root causes and fix bugs. Use when debugging errors, investigating test failures, reproducing bugs from issue trackers (GitHub, Linear, Jira), or when stuck on a problem after failed fix attempts. Also use when the user says 'debug this', 'why is this failing', 'fix this bug', 'trace this error', or pastes stack traces, error messages, or issue references.
Capture a visual demo reel (GIF, terminal recording, screenshots) for PR descriptions. Use when shipping UI changes, CLI features, or any work with observable behavior that benefits from visual proof. Also use when asked to add a demo, record a GIF, screenshot a feature, show what changed visually, create a demo reel, capture evidence, add proof to a PR, or create a before/after comparison.
Based on SOC occupation classification
| name | document-review |
| description | Review requirements or plan documents using parallel persona agents that surface role-specific issues. Use when a requirements document or plan document exists and the user wants to improve it. |
| argument-hint | [mode:headless] [path/to/document.md] |
Review requirements or plan documents through multi-persona analysis. Dispatches specialized reviewer agents in parallel, auto-fixes quality issues, and presents strategic questions for user decision.
Check the skill arguments for mode:headless. Arguments may contain a document path, mode:headless, or both. Tokens starting with mode: are flags, not file paths -- strip them from the arguments and use the remaining token (if any) as the document path for Phase 1.
If mode:headless is present, set headless mode for the rest of the workflow.
Headless mode changes the interaction model, not the classification boundaries. Document-review still applies the same judgment about what has one clear correct fix vs. what needs user judgment. The only difference is how non-auto findings are delivered:
auto fixes are applied silently (same as interactive)present findings are returned as structured text for the caller to handle -- no ask_user_question prompts, no interactive approvalThe caller receives findings with their original classifications intact and decides what to do with them.
Callers invoke headless mode by including mode:headless in the skill arguments, e.g.:
Skill("compound-engineering:document-review", "mode:headless docs/plans/my-plan.md")
If mode:headless is not present, the skill runs in its default interactive mode with no behavior change.
If a document path is provided: Read it, then proceed.
If no document is specified (interactive mode): Ask which document to review, or find the most recent in docs/brainstorms/ or docs/plans/ using a file-search/glob tool (e.g., Glob in Claude Code).
If no document is specified (headless mode): Output "Review failed: headless mode requires a document path. Re-invoke with: Skill("compound-engineering:document-review", "mode:headless ")" without dispatching agents.
After reading, classify the document:
docs/brainstorms/, focuses on what to build and whydocs/plans/, focuses on how to build it with implementation detailsAnalyze the document content to determine which conditional personas to activate. Check for these signals:
product-lens -- activate when the document makes challengeable claims about what to build and why, or when the proposed work carries strategic weight beyond the immediate problem. The system's users may be end users, developers, operators, maintainers, or any other audience -- the criteria are domain-agnostic. Check for either leg:
Leg 1 — Premise claims: The document stakes a position on what to build or why that a knowledgeable stakeholder could reasonably challenge -- not merely describing a task or restating known requirements:
Leg 2 — Strategic weight: The proposed work could affect system trajectory, user perception, or competitive positioning, even if the premise is sound:
design-lens -- activate when the document contains:
security-lens -- activate when the document contains:
scope-guardian -- activate when the document contains:
adversarial -- activate when the document contains:
Tell the user which personas will review and why. For conditional personas, include the justification:
Reviewing with:
- coherence-reviewer (always-on)
- feasibility-reviewer (always-on)
- scope-guardian-reviewer -- plan has 12 requirements across 3 priority levels
- security-lens-reviewer -- plan adds API endpoints with auth flow
Always include:
compound-engineering:document-review:coherence-reviewercompound-engineering:document-review:feasibility-reviewerAdd activated conditional personas:
compound-engineering:document-review:product-lens-reviewercompound-engineering:document-review:design-lens-reviewercompound-engineering:document-review:security-lens-reviewercompound-engineering:document-review:scope-guardian-reviewercompound-engineering:document-review:adversarial-document-reviewerDispatch all agents in parallel using the platform's task/agent tool (e.g., Agent tool in Claude Code, spawn in Codex). Omit the mode parameter so the user's configured permission settings apply. Each agent receives the prompt built from the subagent template included below with these variables filled:
| Variable | Value |
|---|---|
{persona_file} | Full content of the agent's markdown file |
{schema} | Content of the findings schema included below |
{document_type} | "requirements" or "plan" from Phase 1 classification |
{document_path} | Path to the document |
{document_content} | Full text of the document |
Pass each agent the full document -- do not split into sections.
Error handling: If an agent fails or times out, proceed with findings from agents that completed. Note the failed agent in the Coverage section. Do not block the entire review on a single agent failure.
Dispatch limit: Even at maximum (7 agents), use parallel dispatch. These are document reviewers with bounded scope reading a single document -- parallel is safe and fast.
After all dispatched agents return, read references/synthesis-and-presentation.md for the synthesis pipeline (validate, gate, dedup, promote, resolve contradictions, route by autofix class), auto-fix application, finding presentation, and next-action menu. Do not load this file before agent dispatch completes.
@./references/subagent-template.md
@./references/findings-schema.json