plan

name: plan description: "Break a spec, brief, issue tracker item, or user request into agent-sized tasks, delivered to exactly one destination: tracker issues, a plan doc, or chat." user-invocable: true argument-hint: "<spec path, feature slug, task reference, or planning input>"

Turn a spec or user-provided input into tasks for humans, issue trackers, or AI agents. Give each task enough context to execute independently without scripting routine implementation choices.

Workflow

1. Ground in the input

Use $ARGUMENTS, docs/<feature-slug>/spec.md, an issue tracker item, or the current brief as the source input.
Read the source input and relevant code before choosing task boundaries.
Ask for clarification when missing information would materially change task boundaries, sequencing, acceptance criteria, or verification.
If the input is too vague, stop instead of fabricating tasks.

2. Split the work

Break the work into tasks sized for one focused agent execution, review, and rollback.
Prefer vertical slices over layer-by-layer plans.
Order tasks by dependency and risk.
Surface shared decisions once before the affected tasks.

3. Deliver the plan

Specs are durable; plans are transport. Deliver the tasks to exactly one destination, never two:

Tracker: when the user asks for issues or the repo documents an issue-driven loop, file one issue per task and write no plan doc. The issues are the plan. Apply the repo's documented labels: tasks meeting the definition of ready get the agent-ready label; tasks with unmet dependencies get the blocked label with a link to the blocking issue.
Doc: write docs/<feature-slug>/plan.md when there is a clear feature directory.
Chat: return the plan inline otherwise.

For each task, include:

Goal
Context
Relevant files or references
Proposed approach
Acceptance criteria
Source reference
Verify
Out of scope, when it prevents accidental expansion

Rules

Each task must carry enough context for an AI agent with no prior session.
Acceptance criteria describe outcomes, not implementation steps.
Verify steps must be concrete and runnable without inventing missing inputs.
If a task needs many acceptance criteria or mixes unrelated decision clusters, split it.
Include error behavior in the task that owns it.