Planning Document Review

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.

<!-- ce-docs-root:start -->

Resolve the CE artifact root <root> before composing any artifact path.

• Read docs_root from <repo-root>/.compound-engineering/config.yaml only (<repo-root> = git rev-parse --show-toplevel). Do not read it from config.local.yaml. Unset -> <root> is docs, 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 naming docs_root and the value -- never fall back to docs.
• 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 read docs.

<!-- ce-docs-root:end -->

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.