Review Plan

Mode B — envelope-only (dual-source wrapper usage):

• The prompt contains the keyword envelope-only
• Follow the same investigation workflow but DO NOT edit plan files directly
• Instead, emit ONE JSON envelope at the end of your response conforming to .claude/skills/dual-tpr/findings-schema.json
• Each "finding" in envelope-only mode describes a PROPOSED edit — the file path, line number, and the nature of the change — rather than applying the edit in place
• DO NOT modify any files; emit the envelope only
• See .claude/skills/dual-tpr/envelope-format.md for the envelope contract

Execution mode dispatch: (same as review-work)

1. Inspect the prompt for the literal keyword envelope-only
2. If present: proceed in Mode B. All file-editing instructions below are suppressed.
3. If absent: proceed in Mode A. Existing behavior, unchanged.

Scope Inputs

Accept any of these:

• a plan directory:
  • plans/iter-rc-contract/
• a plan file inside the target plan:
  • plans/iter-rc-contract/index.md
  • plans/iter-rc-contract/00-overview.md
  • plans/iter-rc-contract/section-02-elem-dec-fn.md
• a section id or keywords that map to a plan:
  • section-02
  • 02
  • elem_dec_fn
• a plan name or keywords:
  • iter-rc-contract
  • iter rc contract

If the user gives a specific section file or section id, treat it as an entry point to the owning plan. The review still covers the full plan directory, not only that section.

Scope Resolution

Resolve the target in this order:

1. Existing path from the user.
2. Plan match from plans/*/index.md, plans/*/00-overview.md, and plans/*/section-*.md.
3. If the user named a section file or section id, resolve its parent plan directory and review the entire plan.
4. If nothing explicit was given, start with the most relevant recent local plan context:
   • git diff --name-only HEAD -- plans/
   • git diff --name-only --cached -- plans/
   • git diff --name-only -- plans/
   • recent local commits touching plans/
5. If multiple candidate plans remain after step 4, ask one concise question to narrow it.

The scope is the whole owning plan:

• index.md
• 00-overview.md
• every section-*.md file in the plan directory

Do not perform a section-only review with this skill.

Required Inputs To Gather

Build the review packet mechanically before forming conclusions.

1. Plan Inventory

Read the full target plan:

• index.md
• 00-overview.md
• all section-*.md files

Record:

• section ordering and dependencies
• stated mission and success criteria
• status metadata and completion claims
• existing Third Party Review Findings blocks
• sections that look thin, vague, or stale

2. Evidence Packet

Cross-check the plan against the current repository state.

Collect whichever apply:

• git status --short
• recent local commits touching the target plan
• recent local commits touching code paths the plan claims it will modify
• current files, modules, tests, and specs named by the plan
• current staged and unstaged changes that materially affect the plan's claims

From the plan, identify:

• all referenced files, crates, modules, functions, and types
• the tests that should validate each code-modifying section
• adjacent callers, callees, helpers, data definitions, and registration points needed to verify feasibility

Read the full referenced files when they are central to the plan's claims, not only search hits. Expand into neighboring files when needed to verify invariants and downstream impact.

3. Standards Packet

The review is not complete until you have checked the plan against the repository standards.

Always read:

• CLAUDE.md
• .claude/rules/tests.md
• .claude/rules/compiler.md
• .claude/rules/impl-hygiene.md
• .claude/rules/roadmap.md

Also read every file under .claude/rules/*.md before finalizing conclusions. Prioritize rules that match the plan's touched domains first, but the final review must account for the full rule set, marking non-applicable rules as such in your own reasoning rather than silently skipping them.

4. Spec And Plan Context

Gather the surrounding context needed to verify the plan's claims and detect drift:

1. relevant spec files the plan cites or depends on
2. recent plan files changed in the target plan
3. neighboring plans or roadmap entries explicitly referenced by the target plan
4. related plan files touched in recent local history when they change assumptions the target plan relies on

Use this context to answer:

• whether the plan's mission still matches the current roadmap/spec intent
• whether each section still matches the current codebase
• whether cross-plan or cross-section dependencies are reflected accurately
• whether completion claims still match the repository state
• whether existing third-party findings were integrated, silently deferred, or contradicted

Review Workflow

1. Resolve the owning plan and read the entire plan directory in full.
2. Gather the evidence packet, standards packet, and surrounding spec/plan context.
3. Cross-reference every technical claim in the plan against the current codebase, rules, specs, and recent repository history.
4. Reconstruct the plan's mission, execution order, and intended end state from the plan files themselves.
5. Perform an independent verification pass:
   • rerun key tests, scripts, and diagnostics named by the plan when feasible
   • use repo-native debugging or diagnostic workflows before line-by-line speculation when the rule set says to do so
   • verify claims from current outputs, current files, and actual git objects
   • if a cited verification step cannot be reproduced, record that as a verification gap and fix the plan if it made unsupported claims
6. Review with a plan-review mindset:
   • technical inaccuracies
   • infeasible implementation steps
   • missing prerequisites or hidden dependencies
   • broken section sequencing or circular dependencies
   • scope gaps where the mission is only partially covered
   • vague or non-verifiable checklist items
   • missing tests, missing matrix coverage, or missing semantic pins
   • rule violations or hygiene violations implied by the plan
   • plan / implementation drift
   • stale or mishandled Third Party Review Findings
   • partial work presented as complete
7. Edit the plan files directly to fix validated issues:
   • correct inaccurate paths, types, functions, and module references
   • expand thin sections until they are executable
   • add missing prerequisites, test steps, sync points, and cross-section dependencies
   • reorder sections or checklist items when the current sequence is invalid
   • add new sections when the stated mission is not fully covered
8. Preserve every existing reviewed frontmatter value exactly as found. Whole-plan review does not flip, normalize, or rewrite reviewed, even when a section needed corrections.
9. Report findings and substantive edits to the user first, ordered by severity or importance.

Deep Investigation Standard

This is not a plan skim.

• Read the whole plan, not only the file the user named.
• Read enough referenced code to verify that the plan's claims are real and the approach can work.
• Trace dependencies across section, module, crate, and phase boundaries.
• Inspect both tests the plan already names and tests the plan should name but does not.
• Use history and current tree state together to catch stale assumptions hidden by old status text.
• Prefer diagnostics, tracing, and repo-native verification tools over guesswork.

When a plan touches ARC, AOT, lowering, runtime, tests, spec, or roadmap-owned areas, assume the failure surface is wider than a single section and expand the review accordingly.

Mandatory Standards Checks

Every review must explicitly test the plan against these expectations from CLAUDE.md and the