Ce Doc Review
Stress-test a requirements or implementation plan with parallel reviewer personas before you commit engineering time.
Overview
ce-doc-review is an agent skill most often used in Validate (also Build PM, Ship review) that runs parallel persona reviews on requirements or plan documents with safe_auto fixes and guided finding resolution.
Install
npx skills add https://github.com/everyinc/compound-engineering-plugin --skill ce-doc-reviewWhat is this skill?
- Parallel persona agents review one requirements or plan markdown document
- Auto-applies safe_auto fixes where the workflow allows
- Four-option routing: per-finding walk-through, auto-resolve, Append-to-Open-Questions, or report-only
- Optional headless mode via argument-hint for CI-style runs
- Claude Code: preload AskUserQuestion via ToolSearch before interactive questions
- 4 interaction options after parallel review (walk-through, auto-resolve, Append-to-Open-Questions, report-only)
Adoption & trust: 1.6k installs on skills.sh; 20.5k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a requirements or plan doc but no structured way to see blind spots across engineering, product, and ops perspectives before coding.
Who is it for?
Solo builders with a written spec or implementation plan who want multi-angle critique without scheduling a human review round.
Skip if: Empty repos with no document to review, or when you need runtime code analysis instead of document-level review.
When should I use this skill?
A requirements or plan document exists and you want to improve it via parallel persona agents (optional headless: [mode:headless] [path/to/document.md]).
What do I get? / Deliverables
You receive persona-specific findings, optional safe_auto edits applied, and a chosen resolution path for remaining issues on the document you specified.
- Reviewed document with safe_auto edits where applied
- Finding report or resolved items per chosen interaction mode
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
The canonical shelf is Validate because the skill targets requirements and plan documents before full build—catching scope holes early saves the most rework. Scope is where ambiguous requirements and thin plans get refined; multi-persona review surfaces role-specific gaps in that document.
Where it fits
Run persona review on a one-page MVP requirements doc before estimating the build.
Re-review an implementation plan after adding third-party integrations to catch missing rollback steps.
Pass a launch checklist plan through reviewers to surface security and comms gaps pre-release.
How it compares
Use instead of a single generic “review my doc” chat when you want parallel personas plus explicit safe_auto and per-finding decision routing.
Common Questions / FAQ
Who is ce-doc-review for?
Indie developers and tech leads using compound-engineering plugins who maintain requirements or plan markdown and want rigorous review before implementation.
When should I use ce-doc-review?
In Validate when scoping a feature spec; in Build PM when revising an implementation plan; in Ship review when hardening a launch or migration plan—whenever a plan or requirements file exists and you want persona-based issues surfaced.
Is ce-doc-review safe to install?
It can auto-apply safe_auto document edits and asks interactive questions—review the Security Audits panel on this page and use report-only or headless modes if you want zero automatic file changes.
SKILL.md
READMESKILL.md - Ce Doc Review
# Document Review Review requirements or plan documents through multi-persona analysis. Dispatches specialized reviewer agents in parallel, auto-applies `safe_auto` fixes, and routes remaining findings through a four-option interaction (per-finding walk-through, auto-resolve with best judgment, Append-to-Open-Questions, Report-only) for user decision. ## Interactive mode rules - **Pre-load the platform question tool before any question fires.** In Claude Code, `AskUserQuestion` is a deferred tool — its schema is not available at session start. At the start of Interactive-mode work (before the routing question, per-finding walk-through questions, bulk-preview Proceed/Cancel, and Phase 5 terminal question), call `ToolSearch` with query `select:AskUserQuestion` to load the schema. Load it once, eagerly, at the top of the Interactive flow — do not wait for the first question site. On Codex, Gemini, and Pi this preload is not required. - **The numbered-list fallback applies only when the harness genuinely lacks a blocking question tool** — `ToolSearch` returns no match, the tool call explicitly fails, or the runtime mode does not expose it (e.g., Codex edit modes where `request_user_input` is unavailable). A pending schema load is not a fallback trigger; call `ToolSearch` first per the pre-load rule. In genuine-fallback cases, present options as a numbered list and wait for the user's reply — never silently skip the question. Rendering a question as narrative text because the tool feels inconvenient, because the model is in report-formatting mode, or because the instruction was buried in a long skill is a bug. A question that calls for a user decision must either fire the tool or fall back loudly. ## 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. ce-doc-review still applies the same judgment about which tier each finding belongs in. The only difference is how non-safe_auto findings are delivered: - `safe_auto` fixes are applied silently (same as interactive) - `gated_auto`, `manual`, and FYI findings are returned as structured text for the caller to handle — no blocking-question prompts, no interactive routing - Phase 5 returns immediately with "Review complete" (no routing question, no terminal 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("ce-doc-review", "mode:headless docs/plans/my-plan.md") ``` If `mode:headless` is not present, the skill runs in its default interactive mode with the routing question, walk-through, and bulk-preview behaviors documented in `references/walkthrough.md` and `references/bulk-preview.md`. ## 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(\"ce-doc-review\", \"mode:headless <path>\")" without dispatching agents. ### Classify Document Type Classify the d