/ia-document-review

name: ia-document-review
class: workflow
description: >-
  Structural and accuracy review of documents: gaps, clarity, completeness,
  organization, and claims checked against the code. Use when a brainstorm, plan, spec, ADR, or any doc needs polish
  before the next workflow step. For exploring new ideas from scratch, use
  brainstorming instead.

Document Review

Improve brainstorm or plan documents through structured review.

Working rules

• Assess before editing, preserve implementation-relevant constraints and rationale, and distinguish minor edits from substantive decisions.
• A review-only request authorizes findings, not file edits. Apply changes only when the user has requested editing or approved the proposed changes; do not ask again for changes already authorized.

Step 1: Get the Document

**If a document path is provided:** Read it, then proceed to Step 2.

**If no document is specified:** Ask which document to review (via `AskUserQuestion` in Claude Code, `request_user_input` in Codex, or numbered options in chat as the fallback), or look for the most recent brainstorm/plan in `docs/brainstorms/` or `docs/plans/`.

Step 2: Assess

Read through the document and ask:

• What is unclear?
• What is unnecessary?
• What decision is being avoided?
• What assumptions are unstated?
• Where could scope accidentally expand?
• Is this technically feasible with the current architecture?
• Is what it says about the current system true? Follow each checkable claim (file paths, function, command, or config names, endpoints, cited PRs or issues, numbers, behavior implied by verbs like "retries") to its source, reading only. On a long document, sample and state the coverage.
• Are there security implications in what's proposed?

These questions surface issues. Note findings without fixing yet.

Step 3: Activate Review Lenses

Based on the document's content, activate specialized review perspectives. Scan for signals and apply matching lenses:

| Lens | Signals | What it checks | |------|---------|----------------| | **Product** | User-facing features, customer language, market claims, scope decisions | Problem framing, value proposition clarity, whether scope matches stated goals | | **Design** | UI/UX references, user flows, wireframes, interaction descriptions | Flow completeness, interaction gaps, accessibility considerations | | **Security** | Auth/authorization, API endpoints, PII, payments, tokens, encryption | Auth model gaps, data exposure risks, missing threat considerations | | **Scope guardian** | Multiple priority tiers (P0/P1/P2), large requirement count (>8), stretch goals | Scope creep, premature abstractions, features disguised as requirements | | **Adversarial** | >5 distinct requirements, explicit architectural decisions, high-stakes domains | Unstated assumptions, optimistic estimates, single points of failure, missing failure modes |

Activate a lens when ANY of its signals match. Most documents trigger 1-2 lenses; brainstorm notes may trigger none. When a lens is active, weave its checks into the assessment and evaluation steps rather than running it as a separate pass.

Vocabulary signals activate the Security lens; judge it by what named files and handlers do. Report each path the plan names or newly exposes, including existing code or a stub, that leads to lost money, a breach, or corrupted data unprevented.

Step 4: Evaluate

Score the document against these criteria:

| Criterion | What to Check | |-----------|---------------| | **Clarity** | Problem statement is clear, no vague language ("probably," "consider," "try to") | | **Completeness** | Required sections present, constraints stated, open questions flagged | | **Specificity** | Concrete enough for next step (brainstorm → can plan, plan → can implement) | | **YAGNI** | No hypothetical features, simplest approach chosen | | **Accuracy** | Checked claims match their source (Step 2); a contradicted claim is a defect reported with the conflicting `file:line`; claims outside the stated coverage are unverified, not passed |

If invoked within a workflow (after `/ia-brainstorm` or `/ia-plan`), also check:

• **User intent fidelity**: Document reflects what was discussed, assumptions validated

Step 5: Identify the Critical Improvement

Among everything found in Steps 2-4, does one issue stand out? If something would significantly improve the document's quality, this is the "must address" item. Highlight it prominently.

Step 6: Make Changes

Present findings, then:

1. **Apply authorized edits** within the requested scope, including minor wording and formatting fixes. For review-only requests, report these as suggestions. 2. **Ask approval** for changes outside the existing authorization (restructuring, removing sections, changing meaning). Ask via `AskUserQuestion` (Claude Code; load with ToolSearch `select:AskUserQuestion` if not loaded) or `request_user_input` (Codex); fall back to numbered options in chat. Render the finding per the contract below before asking so the decision is concrete. 3. **Update** the document inline only for authorized changes; otherwise return the findings.

Rendering a finding for decision

The reader deciding on a finding does not have the document open and has not memorized its identifiers. This binds the approval track only (step 2 above); findings routed to auto-fix in step 1 skip it. Any finding presented for approval is rendered in this order:

1. **Consequence if unchanged**: one sentence: what goes wrong, and for whom. No identifier the reader would have to look up. 2. **Recommended action**, marked unmistakably. 3. **Change intent**: one sentence. 4. **Mechanism**: at most two sentences, carrying at most two opaque anchors (defined below).

Anything deeper (file tracing, multi-hop call paths, competing call sites) is not printed; offer it in one closing line. Budget: two inline code spans per sentence, no diff blocks, raw code blocks only