| name | implementation-planning |
| description | Use this skill when the user asks to "plan this feature", "write an implementation plan", "design before coding", "think through the approach", "review this plan", or before any multi-file change, architectural decision, experiment with a go/no-go outcome, or strategic pivot. Produces a verifiable plan with pre-registered decision gates and an explicit list of open judgment calls. |
Implementation Planning
Plans that a different (or weaker) model could execute without re-deriving
your reasoning, with success criteria fixed before any result is seen.
Model handoff
Use the strongest available model for problem framing, macro architecture,
irreversible decisions, and plan approval. In Codex this is Sol; in Claude it
is Fable when available, otherwise Opus. After the architecture is approved, a
bounded phase planner may expand it on the intermediate tier (Codex Terra;
Claude Sonnet when no design choice remains). Write the resulting brief so a
clear-task worker (Codex Luna or Claude Sonnet) can implement it without
reconstructing design intent. See agent-fanout for the full routing and
escalation policy.
Pick the register (by stakes, not size)
| Situation | Register |
|---|
| Hard to reverse after shipping; touches privacy, auth, what data leaves the device, or public contracts; strategic pivot | Heavyweight: full plan document, user approval gate before executing (plan mode where available). |
| Known engineering backlog; the work is clear, there is just a lot of it | Lightweight: tracked issues carrying the full spec (template below); no separate plan document. |
| Single ordinary change | No formal plan; the engineering-loop skill's step order is the plan. |
The dividing line is reversibility and blast radius, not effort. A large
backlog of clear fixes needs no plan document; a small change to what an
external partner receives does.
Heavyweight plan: required sections
# Plan: <title> (issue #N)
## Context
[The evidence forcing this work, with numbers. What the previous phase or
investigation proved.]
## What already exists to reuse (do not rebuild)
[Named files/functions. Every plan must check this before proposing new code.]
## Approach
[The design, and one paragraph on why this and not the leading alternative.]
## Files
[New and modified, explicit paths.]
## Decision gate (set BEFORE looking at results)
[Crisp pass/fail: "X ships as default if metric A >= threshold on every
case AND metric B does not regress; if it fails, honest conclusion + named
fallback. No adoption of a non-passing candidate."]
## Prerequisites (user actions)
[Only the human can do these: account registrations, credentials, hardware.]
## Agent budget
[How many subagents this plan will spawn, worst case; see agent-fanout cap.]
## Open judgment calls
[Every ambiguity you resolved unilaterally, as a flagged list the reviewer
can veto. Silence on ambiguity is a defect.]
## Verification
[How each deliverable is proven: commands, thresholds, who runs them. For a
behavior-preserving refactor, the FIRST deliverable is the pin/
characterization test captured against the original code, per the
engineering-loop skill.]
Lightweight register: the issue IS the plan
## Symptom
[User-visible behavior, verbatim if reported.]
## Root cause
[file:line, what is wrong, the fixture/test/commit that proves it.]
## Fix
[Concrete, scoped change. DECIDED POLICY lines for any foreseeable ambiguity.]
Refs: #A, #B.
An implementer (human or agent) executes from the issue alone; that is the
test of whether it is written well enough.
For GitHub issue bodies, keep each paragraph on one source line and separate
paragraphs with blank lines. Do not apply sentence- or clause-level semantic
line breaks inside a GitHub paragraph. Semantic line breaks remain the default
for other prose source.
Non-negotiable planning rules
- Verify load-bearing claims. Before presenting any plan, list the 3-5
facts that would break it if wrong, and re-check each one directly against
source or live state, even when a trusted subagent supplied them.
- Pre-register gates. Success/failure thresholds are written before the
experiment or implementation runs. Re-running with adjusted parameters
without disclosing that the original gate failed is prohibited.
- Check sibling documents. Open issues, ADRs, and plan files in the same
tracker may carry constraints on your deliverable that your source
document does not restate. Surface contradictions before code starts.
- Reuse before rebuild. The "already exists" section is mandatory;
check the codebase and past research before proposing new modules.
- Separate decisions from details. Batch every decision that needs the
user (hard to reverse, quoted to third parties, spends real money or
days of compute) into ONE structured question with 2-4 labeled options,
one marked "(Recommended)", each with a one-line evidence-based rationale.
Decide internal implementation details yourself and state them as facts.
If a question times out unanswered, proceed with the recommended option
and disclose that at the next checkpoint the user will read ("approving
this plan also approves X").
- Persist the plan-of-record outside chat. GitHub epic/issue plus a
Definition of Done with measurable criteria; make gates self-enforcing
where possible (a strict expected-failure test on the exact metric beats
a prose checklist). Conversation history will be compacted; the tracker
survives.
- New information reorders work. When new input contradicts or gates a
decision already acted on, stop downstream work, resolve the upstream
decision first, state why the order flipped, then resume.
- Plans from subagents get verified, not trusted. A planning agent must
be read-only, cite file:line for its claims, and end with its own open
judgment calls; you then re-verify its load-bearing claims (rule 1) before
adopting the plan. Macro architecture uses the lead tier. A bounded phase
elaborator may use the intermediate tier only after architecture approval;
unresolved judgment returns to the lead.
- Kill cleanly. When a gate fails, execute the named fallback: revert
prototype code (with authorization), record the dead end (what was tried,
what it cost, why it failed) in the tracker and scratch notes, and mark
deferred ideas explicitly as deferred, never silently dropped.
Phase sizing (feeds epic-dev)
One phase = one independently reviewable and testable pull request (PR):
roughly one subsystem, one migration, or up to ~500 net lines of
non-generated change.
If the description contains two or more such units, it is an epic (use
epic-dev); if not, it is a single feature (engineering-loop). Name phases
with 2-3 word kebab-case slugs: drop stopwords, keep the object noun first
("backend-metrics", "sync-engine", not "implement-the-new-backend-metrics").
