Document Review
Stress-test requirements or implementation plans with parallel persona reviewers, auto-fix clear issues, and surface strategic questions before you build.
Overview
Document-review is an agent skill most often used in Validate (also Build PM, Ship review) that runs parallel persona reviewers on requirements or plan documents, auto-fixes clear issues, and returns structured findings—
Install
npx skills add https://github.com/everyinc/compound-engineering-plugin --skill document-reviewWhat is this skill?
- Parallel specialized reviewer persona agents on one document
- Phase 0 headless mode (mode:headless) for non-interactive structured findings
- Auto-applies fixes classified as auto; presents judgment calls without forcing chat prompts in headless
- Works on requirements documents and plan documents via argument path
- Phase 5 completes with Review complete in headless without refine questionnaires
- Phase 0 headless detection via mode:headless argument token
- Parallel persona reviewer agents with auto vs present classification
Adoption & trust: 550 installs on skills.sh; 20.5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a requirements or plan markdown file but no systematic way to catch role-specific gaps before your agent or team implements the wrong scope.
Who is it for?
Solo builders with an existing requirements.md or plan doc who want multi-lens review and silent auto-fixes before implementation.
Skip if: Live code review, PR diffs, or repos with no written requirements or plan artifact to point the skill at.
When should I use this skill?
A requirements or plan document exists and you want to improve it via parallel persona review; add mode:headless when the caller must receive findings without interactive approval.
What do I get? / Deliverables
The document gains auto-applied quality fixes plus classified present findings and strategic questions, with headless callers receiving structured output without interactive refine prompts.
- Updated document with auto-classified fixes applied
- Structured present findings for caller decision
- Strategic questions in interactive mode
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Document review belongs on validate/scope as the canonical shelf because it improves requirements and plans before execution—though the same checker applies to build-phase plan docs. Scope subphase is where ambiguous requirements and plan markdown get hardened before prototype or implementation commitments.
Where it fits
Run reviewers on a new PRD to surface missing edge cases before you prototype the landing or API.
Tighten a thin prototype brief so parallel personas catch integration assumptions early.
Re-review implementation_plan.md after scope changes so auto fixes land before coding tasks are dispatched.
Headless pass on a launch checklist doc so a CI or parent agent receives structured present findings without interactive questions.
Quality-pass a content or lifecycle spec document before publishing customer-facing workflows.
How it compares
Targets plan and requirements markdown with persona agents, not a generic linter on source code.
Common Questions / FAQ
Who is document-review for?
Indie developers and small teams using agent workflows who already wrote a requirements or plan document and want parallel reviewer personas before build.
When should I use document-review?
In validate/scope after drafting specs; in build/pm when refining implementation_plan.md; and in ship/review when re-checking plans—use mode:headless when a parent agent must consume findings without chat prompts.
Is document-review safe to install?
It reads and may auto-edit your document paths; confirm scope in your repo and review the Security Audits panel on this Prism page before running on sensitive specs.
SKILL.md
READMESKILL.md - Document Review
# Document Review 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. ## Phase 0: Detect Mode 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 AskUserQuestion prompts, no interactive approval - Phase 5 returns immediately with "Review complete" (no refine/complete question) The 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. ## Phase 1: Get and Analyze Document **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 <path>\")" without dispatching agents. ### Classify Document Type After reading, classify the document: - **requirements** -- from `docs/brainstorms/`, focuses on what to build and why - **plan** -- from `docs/plans/`, focuses on how to build it with implementation details ### Select Conditional Personas Analyze 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: - Problem framing where the stated need is non-obvious or debatable, not self-evident from existing context - Solution selection where alternatives plausibly exist (implicit or explicit) - Prioritization decisions that explicitly rank what gets built vs deferred - Goal statements that predict specific user outcomes, not just restate constraints or describe deliverables *Leg 2 — Strategic weight:* The proposed work could affect system trajectory, user perception, or competitive positioning, even if the premise is sound: - Changes that shape how the system is perceived or what it becomes known for - Complexity or simplicity bets that affect adoption, onboarding, or cognitive load - Work that opens or close