/ln-33-plan-reviewer

name: ln-33-plan-reviewer
description: "Reviews a concrete implementation plan for missing decisions, feasibility and risk before execution; read-only."

Plan Reviewer

**Goal:** Perform a read-only, evidence-first second pass over an implementation plan. Verify the plan; do not execute it. A strong result is decision-complete, grounded in the actual repository, explicit about uncertainty, no more complex than the problem requires, and expressed in the fewest words and execution steps that preserve safety.

**Execution contract:** The checklist defines completion. Track each item internally as `PENDING`, `PROVEN` with evidence, `CLEARED` with evidence its condition is absent, or `UNPROVEN` with a gap; reading, delegation, or tool failure is not proof. Reconcile after each section. Before returning, resolve all `PENDING`, count only `PROVEN` and `CLEARED`, and apply verdict and approval rules to every gap. Preserve intent, scope, and existing authorization. Continue authorized work; ask only for consequential unresolved choices or required external approval. Scale depth to material risk without skipping checks. Preserve dependency and safety order; otherwise choose an appropriate verification method. Accept equivalent user or repository evidence; no other skill, named artifact, or complete lifecycle is required. Preserve source requirement and decision IDs. Bind reused evidence to relevant source versions, dirty changes, configuration, and environment; invalidate only affected claims. On continuation, reconcile task, authorization, current state, and unresolved evidence. For long work, return a compact continuation record or update an already authorized artifact; read-only skills do not persist it. Distinguish artifact readiness, verified behavior, and external-action authority. Prepare authorized work before required approval. If blocked by an instruction, cite its exact source and unresolved boundary; do not invent approval gates from caution.

Tool Routing

| Need | Preferred tool | Use it when | Fallback | |---|---|---|---| | Repository instructions and current state | Native file read plus Git | Always read the active host's applicable repository instructions; use `git status`, `diff`, and history when branch or change context matters | Equivalent host file and shell tools | | Paths, text, config, docs, and focused code reads | Native file listing, search, outline, and range reads | The question is textual or structural and does not require symbol identity | Narrow the path and pattern before expanding content | | Symbols, references, callers, implementations, cycles, and blast radius | Language server or host-native code intelligence | A plan changes existing code relationships, public APIs, module boundaries, or architecture | Targeted search plus direct inspection of definitions and consumers | | Planned edit risk | Code intelligence plus caller and consumer search | The plan names an edit region, route, event, response contract, or existing change surface | Inspect named symbols and adjacent integration points manually | | Build, test, migration, and script feasibility | Repository-defined commands through the shell | The plan depends on a command, baseline, generated artifact, or existing test surface being available | Inspect scripts and CI configuration; mark execution unverified | | Correction and external-claim research | Official vendor documentation, specifications, or standards through documentation search or the web | External behavior or a correction depends on changing platform semantics | Reputable primary engineering material; otherwise mark the claim or correction `UNVERIFIED` | | Independent challenge | Native subagents in separate contexts | A plan benefits from execution, fresh-context, or adversarial perspective | Run the selected perspectives once as one bounded self-review batch and report reduced independence |

Use the preferred tool only when it answers the current evidence question. Tool failure is not a domain finding: report reduced confidence and block only when missing evidence prevents a safe decision. Do not use semantic tooling for prose or configuration questions, and do not use web research to rediscover stable local facts.

Evidence Rules

| Evidence | Authority | |---|---| | Repository files, manifests, schemas, generated contracts, and executable behavior | Source of truth for the current project state | | Official vendor documentation, specifications, RFCs, and security standards | Source of truth for external contracts and current supported behavior | | Release notes and migration guides matching the project's actual version range | Source of truth for compatibility and upgrade claims | | Reputable primary engineering material | Supporting evidence when official sources do not address a design tradeoff | | Community discussion or training knowledge | Leads only; never sufficient for a blocking factual claim |

When sources disagree, prefer the repository for what is installed and implemented, and official documentation for what an external system promises. Repository evidence proves a plan defect; external practice sources justify the correction mechanism and cannot invent a local requirement. State disagreements instead of silently choosing the convenient answer.

Checklist

1. Establish the Review Contract

• [ ] Resolve the exact plan, user request, linked requirements, and repository scope. If no concrete plan exists, stop with `BLOCKED` rather than inventing one to review.
• [ ] Read all applicable repository instruction files before interpreting code, documentation, or expected workflow. Identify only change-relevant project policies, standards, and ADRs; distinguish current accepted authority from draft, superseded, stale, or merely descriptive material instead of treating every document as binding.
• [ ] Inspect Git state when it can affect the review: current branch, uncommitted changes, comparison base, and r