ce-doc-review
everyinc/compound-engineering-plugin
Review requirements, plans, or specs with role-specific lenses to improve planning documents.
What is ce-doc-review?
A document review skill that analyzes requirements, plans, or specifications through multiple expert perspectives to identify problems that would affect execution. Use it when you want to improve an existing planning document before work begins.
- Dispatches role-specific reviewer personas (coherence, feasibility, security, adversarial, product) based on document content and signals
- Identifies problems that change work outcomes or materially hinder execution, not minor style issues
- Verifies findings against the whole document, project facts, and settled decisions
- Applies authorized corrections within existing decision authority
- Returns structured findings with verified consequences for agreed work
How to install ce-doc-review
npx skills add https://github.com/everyinc/compound-engineering-plugin --skill ce-doc-review- A readable planning document in markdown or HTML format
- Compound Engineering plugin installed (npx skills add)
- Optional: `.compound-engineering/config.yaml` with custom `docs_root` if not using default `docs/` directory
How to use ce-doc-review
- 1.Install the skill: `npx skills add https://github.com/everyinc/compound-engineering-plugin --skill ce-doc-review`
- 2.Prepare your planning document (requirements, plan, or spec in .md or .html)
- 3.In interactive mode: run the skill with no arguments to review the most recent plan, or provide a path to a specific document
- 4.In non-interactive mode: run with the document path as an argument to get structured findings
- 5.Review the findings from each persona, verify their consequences, and approve or reject corrections
- 6.Apply authorized corrections and confirm the review is complete
Use cases
- Review a requirements document before development to catch feasibility or security gaps
- Analyze a project plan for coherence and internal consistency before execution begins
- Check a specification for adversarial vulnerabilities or product-market fit issues
- Validate that a unified artifact (requirements + implementation plan) covers all necessary aspects
- Improve a planning document with multi-lens feedback before committing to work
- Engineering leads and architects reviewing planning documents
- Product managers validating requirements before handoff
- Security-focused reviewers checking specifications for risk
- Teams using Compound Engineering for structured planning
ce-doc-review FAQ
It reviews requirements documents, implementation plans, unified artifacts (combining requirements and planning), and specifications in markdown or HTML format. Classification is based on content, not file labels.
It always uses coherence and feasibility reviewers, then conditionally activates security, adversarial, and product lenses based on signals in the document content (e.g., sensitive data triggers security review, novel features trigger product review).
The skill reports which reviewers completed, failed, or could not run and why. Failures are named in Coverage; the review continues with available results unless capacity cannot recover.
Yes. You can provide an absolute path to any document outside a repo. The skill only requires a readable markdown or HTML file; it does not depend on a repo root or CE config unless you use interactive mode with the default plan discovery.
Interactive mode discovers the most recent plan and guides you through grouped confirmation and per-finding walk-throughs. Non-interactive mode takes a document path and returns structured findings as text, suitable for automation or scripting.
Full instructions (SKILL.md)
Source of truth, from everyinc/compound-engineering-plugin.
name: ce-doc-review description: Review requirements, plans, or specs with role-specific lenses. Use when the user wants to improve an existing planning document. argument-hint: "[mode:non-interactive] [path/to/document.{md,html}]"
Document Review
Help the author finish a sound document they can use to carry out the agreed work. Find problems that would change that work's outcome or materially hinder execution, and resolve them within the authority already given. Judge the document by whether it guides correct work, not by how much detail it contains. Serious consequences warrant attention even when the defect is small. An adequate document needs no changes.
Reviewer personas supply evidence; the judgment is yours. Check their claims against the whole document, project facts, and settled decisions. Correct proven errors that prevent an existing decision from being carried out, within the edit authority and reviewer requirements the synthesis reference states. Return only worthwhile improvements still needing permission, consequential choices or essential information only the user can supply, and useful observations.
Done when: every selected reviewer has returned or is named as failed in Coverage, retained findings have a verified consequence for the agreed work, and every authorized correction assigned to Apply has been made and checked. Report that final state through the interactive approval or decision process, or return it as structured text in non-interactive mode.
Interactive mode rules
Read references/modes.md before anything else. It defines how the mode is detected, the non-interactive argument contract, and the question-tool rules: match the host's blocking question tool already in the current tool list (never call a user-facing question tool to discover it), pre-load it at the top of the interactive flow if it is listed but unloaded, and fall back to a numbered list only when the harness genuinely lacks one.
Either way, a question that calls for a user decision calls the tool or falls back loudly. Narrating it as plain text is a bug.
Artifact Root
Resolve <root> only in the no-path interactive branch, which discovers the most recent plan under <root>/plans/. Every other run reads the document at the path it was handed. So an absolute-path or non-interactive review — /tmp/plan.md, possibly outside any repo — never depends on a repo root or a CE config it does not need.
Resolve the CE artifact root <root> before composing any artifact path.
- Read
docs_rootfrom<repo-root>/.compound-engineering/config.yamlonly (<repo-root>=git rev-parse --show-toplevel). Do not read it fromconfig.local.yaml. Unset -><root>isdocs, exactly as before. - Validate a set value: a repo-relative directory whose real, symlink-resolved path stays inside the repo and is neither the repo root nor under
.git/. Otherwise stop with an error namingdocs_rootand the value -- never fall back todocs. - Use
<root>as the sole artifact location: create it if absent, compose each path as<root>/<subdir>with this skill's own subdirectory, and never also readdocs.
Phase 1: Get and Analyze Document
Read references/document-intake.md now. It covers how the document is obtained in each mode, what to do and say when no document is found, and the classification signals.
Two of its rules apply to every later step.
Verify before any dispatch. Every resolved path must be readable on disk. If one is not, dispatch no personas: reviewers read from the filesystem, so they cannot reach a path that exists only on an unchecked-out branch (issue #925).
Classify by content, not readiness labels or file path. A unified artifact with only a Product Contract is unified-requirements; missing implementation sections are expected. Any implementation planning makes it unified-plan, including incomplete or blocked planning that needs review. Other artifacts use the legacy requirements / plan split.
HTML unified artifacts take the same routes. Every fix lands in the document's native format; never insert markdown into HTML. That reference covers ID-bearing items. Pass the classification to each persona in the {document_type} slot.
Phase 2: Announce and Dispatch Personas
Skip dispatch only when the completed-review reuse condition in references/document-intake.md passes; continue with that evidence at Phase 3.
Read references/persona-selection.md for each conditional persona's activation signals and the announcement format. Two of those signals over-activate on plausible evidence: the sensitive-data bound on security-lens-reviewer, and the challenge-surface bar on adversarial-document-reviewer. Then read references/dispatch.md for payload variables, slicing, model tiering, and reviewer-failure handling.
The team is coherence-reviewer and feasibility-reviewer always, plus each activated conditional persona. Announce the team with a per-persona justification before any dispatch.
Dispatch generic subagents with bounded parallelism through the platform's subagent primitive. Seed each one with the full content of its references/personas/<reviewer-name>.md. Never dispatch a standalone agent by type or name.
A capacity rejection is backpressure, not reviewer failure: wait and retry. If capacity cannot recover and selected reviewers remain undispatched, collect and clean up any started cross-model jobs as references/cross-model-review.md describes, then stop as incomplete without synthesis, fixes, or a success handoff. Preserve collected outcomes and report which reviewers completed, failed, or could not run, and why.
Cross-Model Judgment Pass
Run this pass if any of the conditional judgment trio was activated: adversarial-document-reviewer, product-lens-reviewer, security-lens-reviewer. Follow references/cross-model-review.md, which defines the whole pass: confirming the host, the one target and route used for the whole document, the disclosure before anything leaves the machine, and how peers are launched, collected, and folded in.
The pass is additive and non-blocking: a failure or timeout stops nothing and is named in Coverage. The checkout's cross_model_review_mode setting is checked first and can skip the pass with a named reason. Filter recipients only when CROSS_MODEL_PEERS is set — unset means unfiltered, not unsanctioned. Never silently change an explicit model or recipient.
Phases 3-5: Synthesis, Presentation, and Next Action
Wait until every dispatched agent has returned, including any cross-model <reviewer-name>-<provider>.json returns. Then read references/synthesis-and-presentation.md. It defines synthesis, how each finding is routed by confidence and fix class, fix application, the non-interactive result format, and the handoff to the routing question. When promoting agreement, only an artifact with independence_verified: true counts as an independent reviewer.
Interactive mode only. Read references/walkthrough.md for the grouped confirmation, the routing question, and the per-finding walk-through. Read references/bulk-preview.md for the bulk-action preview behind best-judgment routing, Append-to-Open-Questions, and auto-resolve. Load neither before review evidence is complete, whether newly collected or validly reused, and a non-interactive run never loads them at all — it stops at the structured review result.
Read only the persona prompts the current review selected. The template and schema the dispatch payload fills:
@./references/subagent-template.md
@./references/findings-schema.json
Related skills
More from everyinc/compound-engineering-plugin and the wider catalog.

ce-frontend-design
Build production-grade web interfaces with intentional design, not generic AI aesthetics.

ce-gemini-imagegen
Generate and edit images with Google's Gemini API—text-to-image, style transfer, logos, and multi-turn refinement.

ce-ideate
Generate and evaluate grounded ideas before choosing one to develop.

ce-optimize
Optimize a named target with a measured loop: score variants and keep winners when the winning change isn't known.

ce-plan
Create structured plans for multi-step work, including software and non-software tasks.

ce-polish-beta
Start a dev server, open the feature in a browser, and iterate on improvements together.