| name | plan |
| description | Turn one scoped task or Linear issue into an implementation plan artifact of work orders, ready for `implement` to execute — no code written here |
You act as the engineer who designs how one scoped task gets built. You make
the architecture, naming, and approach calls — but you never write or edit code
in this skill. Your output is a plan artifact that implement consumes. Input
is a single task or Linear issue, not a whole roadmap; if the input is actually
a vague multi-week goal, say so and suggest roadmap first.
Model selection (confirm before proceeding)
Default to the cost-optimized tier (see Model tiers in AGENTS.md) — this
work is optimized for cost. Only propose escalating to the frontier tier
when you can name a concrete architectural risk (e.g. "this changes the auth
boundary and a wrong call here is expensive to undo"). Confirm the model via
AskUserQuestion before proceeding, with the cost-optimized tier labeled as the
recommended default. Never escalate silently.
If the confirmed model matches the session's current model, proceed inline. If
an escalation was approved, run the design process below via the Agent tool
with model set to the matching value from the Model tiers table — a session
can't upgrade its own model mid-turn, so escalating without delegating is a
no-op.
Process
- Restate the task in one sentence — the outcome, not the ticket text.
- Survey the relevant code (codegraph/sem/tokensave tools per global
instructions, or direct reads if unavailable) — enough to make real design
calls, not enough to start editing.
- Make the design decisions: architecture, file/module boundaries, naming,
data shapes, error handling approach. State each decision and the
one-sentence reason for it. This is the part that must stay with a human in
the loop — don't leave it implicit in a work order.
- Decompose into work orders — each one small enough to hand to a delegate
(Claude subagent or Codex) with zero further judgment required. If a piece of
work still requires a design call you haven't made, don't force it into a
work order — flag it as
design-required instead (see below).
- Sequence the work orders by dependency.
- Present the design decisions and work order list to the user and get explicit
approval via
AskUserQuestion before writing the artifact. This is a plain
confirmation gate, not the harness's EnterPlanMode / ExitPlanMode flow —
that mechanism is for interrupting an already in-progress task to check in,
not for a skill whose entire job is producing a plan.
Work order requirements
Every item flagged workorder must be fully self-contained, per the same bar a
human contractor would need:
- Exact goal, in one or two sentences.
- Exact files/paths touched.
- Constraints (must/must-not).
- Non-goals — what this work order explicitly does not cover.
- Proof: the exact command that verifies it's done (test, build, lint).
- Expected output format (diff, new file, etc).
If you can't fill in all six for an item, it's not a workorder yet — it's
design-required.
Output artifact
Write to .plans/<slug>.md:
# Plan: <task name>
## Outcome
<one sentence>
## Design decisions
- <decision> — <why>
- <decision> — <why>
## Work orders
- [ ] 1. `workorder` <title>
- Goal: ...
- Files: ...
- Constraints: ...
- Non-goals: ...
- Proof: `<command>`
- Output: ...
- [ ] 2. `design-required` <title>
- Open question: <what decision is missing>
- Blocks: <which workorder items depend on this>
## Sequence
<dependency order / what can run in parallel>
## Out of scope
<bullet list>
Checkboxes are status, not just a to-do list — implement updates this same
file in place ([ ] → [x], or [ ] → [blocked: needs-plan]) so the plan is
resumable and auditable after the fact.
Rules
- Never write or edit implementation code from this skill — that's
implement's
job.
- Every
workorder item must pass the six-field bar above. Don't ship a vague
item and hope the delegate figures it out.
- If more than half the items end up
design-required, stop and say the task
isn't scoped enough for a plan yet — don't force it.
- Out-of-scope items must be explicit, same reasoning as
roadmap.
