Create a work plan for the following task: $ARGUMENTS
Instructions
Research first. Read MEMORY.md, backlog/INDEX.md, and any relevant state/ or references/ files to understand current state and prior work. Check plans/completed/ for related past tasks. Check backlog/ for an existing draft plan that matches this task.
Create or activate the plan file. If a draft plan exists in backlog/, move it to plans/, update its date to today, and set status to active. Refine the plan based on your research. If no draft exists, write a new file at plans/YYYY-MM-DD-<slug>.md where the slug is a short kebab-case name derived from the task. Use today's date. Use this format:
# Task: <Descriptive Name>
- **Date**: YYYY-MM-DD
- **Status**: active
## Objective
What we're trying to accomplish and why. Be specific.
## Plan
1. Step one
2. Step two
3. ...
**Artifacts:** Where deliverables will be stored (e.g. `artifacts/`, `artifacts/<subfolder>/`).
**Files to create/modify:** List every file and folder expected to be created, moved, or significantly changed — including which `INDEX.md` files will need updating.
**Success criteria:**
- [ ] Criterion A
- [ ] Criterion B
Leave the sections below the plan blank — they get filled in during and after execution:
## Outcome
_Fill in when completed._
## Key Decisions
_Fill in when completed._
## Artifacts
_Fill in when completed._
## Session Log
_Fill in when completed._
Present and clarify. Assume the user hasn't read the research and doesn't know this corner of the project. One or two sentences each: what the situation is, what the work will produce, and what it deliberately won't cover. No numbered walkthrough of the steps and no success-criteria checklist — those stay in the plan file for the executor.
Then surface the scope decisions, trade-offs, and assumptions that genuinely need the user. Use the AskUserQuestion tool with concrete options — don't ask open-ended questions when specific choices are available, and make every option differ in something the user can judge without opening a file: what the deliverable achieves, who it's for, what it costs, what it rules out later. Group related decisions (up to 4 per question).
Decide artifact placement yourself using the Whole-File Test in CLAUDE.md and state where things will land in a clause — never ask which folder. Skip clarification if the task is absolutely straightforward. Update the plan file with the user's answers. Wait for approval before any work begins.
Do NOT execute the plan. This skill only creates and proposes the plan. Execution happens via the /execute skill after the user approves.
Scope check. Plans in non-code repos must never include implementing code changes. This workflow produces content, research, specs, and briefs — not code. If a task involves building something in an app, the plan should cover producing the content/spec/brief that the user takes to the coding repo.
1---2name: plan3description: Create an ops work plan for a new task. Proposes steps and success criteria for user approval before execution.4---56Create a work plan for the following task: $ARGUMENTS78## Instructions9101. **Research first.** Read `MEMORY.md`, `backlog/INDEX.md`, and any relevant `state/` or `references/` files to understand current state and prior work. Check `plans/completed/` for related past tasks. Check `backlog/` for an existing draft plan that matches this task.11122. **Create or activate the plan file.** If a draft plan exists in `backlog/`, move it to `plans/`, update its date to today, and set status to `active`. Refine the plan based on your research. If no draft exists, write a new file at `plans/YYYY-MM-DD-<slug>.md` where the slug is a short kebab-case name derived from the task. Use today's date. Use this format:1314```markdown15# Task: <Descriptive Name>1617- **Date**: YYYY-MM-DD18- **Status**: active1920## Objective21What we're trying to accomplish and why. Be specific.2223## Plan241. Step one252. Step two263. ...2728**Artifacts:** Where deliverables will be stored (e.g. `artifacts/`, `artifacts/<subfolder>/`).2930**Files to create/modify:** List every file and folder expected to be created, moved, or significantly changed — including which `INDEX.md` files will need updating.3132**Success criteria:**33- [ ] Criterion A34- [ ] Criterion B35```3637Leave the sections below the plan blank — they get filled in during and after execution:3839```markdown40## Outcome41_Fill in when completed._4243## Key Decisions44_Fill in when completed._4546## Artifacts47_Fill in when completed._4849## Session Log50_Fill in when completed._51```52533. **Present and clarify.** Assume the user hasn't read the research and doesn't know this corner of the project. One or two sentences each: what the situation is, what the work will produce, and what it deliberately won't cover. No numbered walkthrough of the steps and no success-criteria checklist — those stay in the plan file for the executor.5455 Then surface the scope decisions, trade-offs, and assumptions that genuinely need the user. Use the **AskUserQuestion** tool with concrete options — don't ask open-ended questions when specific choices are available, and make every option differ in something the user can judge without opening a file: what the deliverable achieves, who it's for, what it costs, what it rules out later. Group related decisions (up to 4 per question).5657 Decide artifact placement yourself using the Whole-File Test in `CLAUDE.md` and state where things will land in a clause — never ask which folder. Skip clarification if the task is absolutely straightforward. Update the plan file with the user's answers. Wait for approval before any work begins.58594. **Do NOT execute the plan.** This skill only creates and proposes the plan. Execution happens via the `/execute` skill after the user approves.60615. **Scope check.** Plans in non-code repos must never include implementing code changes. This workflow produces content, research, specs, and briefs — not code. If a task involves building something in an app, the plan should cover producing the content/spec/brief that the user takes to the coding repo.
OdinMB