Planning

Produce an executable plan, or strengthen an existing one. Planning alone produces no implementation edits. When the user asks to plan and implement, finish the plan and continue within the host's active mode and authorization.

• Create: no plan exists; ground the approach in the repository and write the plan.
• Review: a plan exists; verify its consequential claims and resolve concrete gaps in the file.
• Interview: the user asks to be grilled or interviewed; explore decisions interactively.
• Split: multiple independently deliverable outcomes need tickets with native dependency links.

For architecture contracts use codebase-architecture; for code findings use tidy.

References

File	Read when
references/decision-briefs.md	Presenting a consequential decision to the human: measuring options, previews, recording the answer
references/interrogation-protocol.md	Choosing which question to ask about an unresolved choice, or the user requested an interview
references/doc-grounding.md	ADRs, specifications, or library docs constrain the approach
references/handoff-plans.md	Another session or person will execute the plan
references/plan-quality-rubric.md	Reviewing completeness, feasibility, scope, testability, risk, and assumptions
references/questioning-framework.md	A review gap needs a focused user question
references/claim-verification.md	A plan claim can be checked against code or documentation
references/splitting.md	Decomposing work into executable tickets

Workflow

1. Identify the requested outcome and authoritative plan path. Use the host's plan file where one exists. A durable handoff goes at the project path, default docs/plans/<slug>.md; name which copy is authoritative.
2. Inspect the modules, tests, and decisions that constrain this change. Resolve questions the repository answers yourself. Ask only when an unresolved choice materially changes scope, behavior, or a hard-to-reverse action. Routine assumptions belong in the draft. Before asking, measure the options and name what would flip your recommendation; when that hinge is a fact only the human has, ask about it directly (references/decision-briefs.md).
3. Choose the smallest vertical slice that exercises the real boundary. Name the existing code or platform capability it extends. A new dependency or abstraction needs a current requirement the existing mechanism cannot satisfy.
4. Write the plan with the contract below. Review the consequential claims once against the rubric; fix evidenced gaps directly. A handoff plan also gets the stranger test in references/handoff-plans.md. Interview mode can explore competing approaches, but has no minimum question count.
5. Return the plan path, unresolved decisions, and verification limits. Use the host's approval mechanism when its mode requires it. Do not add a second approval question for the plan's own review.

Plan contract

Include only sections this change needs:

• Outcome: triggering problem, intended behavior, and acceptance criteria. Requirements from a client or meeting cite their source (timestamp, document version, screenshot) and are marked decided, proposed, or inferred.
• Approach: chosen slice, affected files or interfaces, and migration order where applicable.
• Decisions: a decision log: question, choice, who decided and when, measured evidence per option, and what would flip it; assumptions that remain unverified.
• Boundaries: exclusions only where an adjacent change would plausibly be mistaken for scope.
• Verification: a command, test scenario, or observation tied to each material acceptance criterion, including expected failure behavior.
• Docs: which current docs (those the repository marks as kept true, such as a "Current" entry in its docs index) this change makes wrong, updated in the same PR.
• Recovery: rollback or recovery for migrations and irreversible writes.

A handoff is self-contained. Replace "as discussed" with the decision. Preserve user corrections in the file, not just the chat. Split tickets by shippable outcome, not database/backend/frontend layers.

Review completion

Resolve gaps supported by code, the task, or operational constraints. Do not add speculative requirements to improve a self-score. Scores are optional unless requested; when used, mark unverified claims and explain residual gaps rather than iterating until every cell says 5/5.

Repeat review only after a substantive edit or new evidence. A user decision that remains unanswered is recorded at the affected step; continue independent work. If the user says to skip questions, draft from available evidence and label the assumptions.

Gotchas

• A plan in ~/.claude/plans/ is not available to other checkouts or CI. Durable handoffs need a project artifact.
• A bare "run tests" step does not establish the changed behavior. Name the acceptance scenario and expected result.
• Publishing slices without native blocker relations leaves the execution queue unaware of dependencies.
• A summary or partial retrieval of a transcript or document is not a read of it; record which sources were read in full and never report partial coverage as full.
• A realistic placeholder (demo login, fake key, guessed domain or role) reads as decided and ships. Mark each gap missing and name who supplies it; an unstated deadline or budget is "unknown", not zero or unlimited.
• "Done" can mean tests pass, merged, live and verified, or accepted by the requester; each verification criterion names which one it establishes.
• A plan written for a prior revision can name moved files. Verify consequential paths and interfaces against the current checkout.

Maintenance only: evals/evals.json contains regression scenarios for changes to this skill; it does not load during a user task.