plan-feature

name	plan-feature
description	Turn a feature request into a concrete plan — scope, approach, affected files, a test plan mapped to acceptance criteria, and out-of-scope — before any code is written. Use when the user describes new work, asks to design or spec something, or says "plan this" / "how would you build X".
model	opus
effort	high
allowed-tools	["Read","Grep","Glob","Bash"]
argument-hint	<feature request or ticket id>
triggers	["plan this","how would you build","design a","spec out","what's the approach"]
tags	["planning","design","spec","pipeline"]

Plan Feature

Produce a plan good enough that implementation is mechanical. This is the first pipeline step (plan → track → implement → review → pr). Planning is reasoning- heavy — run it on a strong model at high effort.

Start

1. Recall first. Check injected memory and pull related context:

node "${CLAUDE_PLUGIN_ROOT}/hooks/memory.mjs" reply "<feature keywords>"

Don't re-plan something already decided — build on it.

2. Read the ground truth: the relevant source, existing tests, and docs. Use Grep/Glob to find the real files this touches. Never plan against assumptions when the code is right there.

The plan (produce all sections)

• Scope — what this delivers, in one paragraph. Quote the user's acceptance criteria verbatim if given; otherwise state the criteria you infer and confirm.
• Approach — the solution shape: components, interfaces, data flow, error handling. Name the trade-off you chose and the one you rejected, and why.
• Affected files — the actual repo paths to add or change (source, tests, docs). This becomes the implementer's file map.
• Test plan — every acceptance criterion maps to at least one test. Name the project's test runner and the exact command.
• Out of scope — adjacent things you are deliberately not doing.
• Open questions — anything genuinely ambiguous. Ask the user these BEFORE finishing (batch them into one interaction). Don't invent product decisions.

Persist

Create or update the ticket and mark planning done:

# create a ticket if this is new work (prints the id, e.g. HZ-1)
node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" new "<feature title>" --type story

# record the plan as a durable decision + mark the step done
node "${CLAUDE_PLUGIN_ROOT}/hooks/memory.mjs" keep "<one-line plan summary + key decision>" --kind decision --tags plan
node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" step <ticket-id> plan done --note "<short>"

Rules

• Plan against reality, not guesses — read the code first.
• Every acceptance criterion needs a test in the plan. No orphan criteria.
• Don't design beyond the request. YAGNI: the smallest plan that satisfies the criteria wins.
• If scope is a big feature, propose splitting it into tickets and hand off to track-work.

Finish

Present the plan, the ticket id, and the next step: track-work to break it down, or implement to build it. Under ship, return a one-line summary and the ticket id.