plan

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

1. Restate the task in one sentence — the outcome, not the ticket text.
2. 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.
3. 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.
4. 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).
5. Sequence the work orders by dependency.
6. 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.