plan

Create a clear, implementation-ready PRD for a single feature (not code).

Guardrails

Do not implement the feature.
If the user asks to implement, propose writing a PRD first (or ask if they want to skip the PRD).
Prefer asking a small number of high-value questions; otherwise write a draft PRD with explicit assumptions.
Write the PRD so a junior dev (or another AI) can implement it without extra context (plain language, explicit edge cases, verifiable acceptance criteria).
Treat memory capture as built-in: if planning introduces durable decisions/constraints, update
```
tasks/memory.md
```
in this step.

Workflow

Identify the feature:
- Prefer a feature ID like
```
f-01
```
  if available.
- If
```
tasks/todo.md
```
  exists, use the matching feature entry as the baseline for outcome + scope.
- If the feature entry includes
```
Type:
```
  , carry it into the PRD Summary so
```
implement
```
  can branch and implement appropriately.
- If
```
Type:
```
  is missing, assume
```
Type: feat
```
  .
- If
```
tasks/todo.md
```
  is missing or the feature is not in it yet, stop and use
```
new
```
  to add the feature to
```
tasks/todo.md
```
  first.
- If
```
tasks/memory.md
```
  exists, skim relevant key decisions / notes before finalising requirements.
Check priority (if
```
tasks/todo.md
```
exists):
- Priority is determined by list order (higher in the list = higher priority).
- If there are higher-priority unchecked items above this feature, ask the user to confirm they want to proceed (vs writing a PRD for one of the higher-priority items first). Mention the higher-priority IDs/names.
- If the user says this item is urgent, recommend switching to
```
new
```
  to move it higher in
```
tasks/todo.md
```
  , then return to
```
plan
```
  .
Determine the PRD file path:
- First look for an active PRD matching the feature ID in
```
tasks/
```
  (
```
tasks/f-##-*.md
```
  ).
- If one exists, use it.
- Otherwise use
```
tasks/f-##-<feature-slug>.md
```
  (include the feature ID in the filename).
If a PRD already exists at that path, update it in place (do not create a duplicate PRD unless the user asks). Do not reset any existing checklist items inside the PRD.
Ask essential clarifying questions (lettered options) only when needed.
Confirm scope boundaries (in-scope vs non-goals) and success metrics.
Write or update the PRD at the chosen path (create
```
tasks/
```
if missing):
- Ensure implementation progress is trackable via checklist items (for example, user stories and acceptance criteria checkboxes).
- If
```
tasks/todo.md
```
  lists
```
Dependencies:
```
  for this feature, include them in "Dependencies & Constraints" (dependency validation happens during
```
implement
```
  ).
If
```
tasks/todo.md
```
exists, update it to reflect the PRD:
- Check the feature checkbox (
```
- [ ]
```
  →
```
- [x]
```
  ).
Evaluate memory-worthy outcomes and update
```
tasks/memory.md
```
inline when needed:
- architecture or requirement decisions with durable impact
- new constraints, non-goals, or rollout assumptions
- risk decisions likely to affect later implementation/review
Reply with updated file paths and a short summary + open questions.

Clarifying Questions (Only If Needed)

Ask up to ~7 questions. Use numbered questions with A/B/C/D options and an Other option so the user can reply like

1B, 2D, 3A

Cover only what is ambiguous:

which feature this PRD is for (feature ID/name)
user + use case
problem + desired outcome
scope boundaries (in scope vs out of scope)
whether this is
```
Type: feat
```
vs
```
fix
```
vs
```
chore
```
feature dependencies (by feature ID)
conflicts with existing decisions/constraints (from
```
tasks/memory.md
```
)
platforms/surfaces
data + permissions
integrations / external dependencies
success metrics
rollout constraints / timeline

Example question format

text

1. What is the primary goal?
   A. Enable a new capability
   B. Improve an existing workflow
   C. Reduce cost / time / errors
   D. Other: [describe]

PRD Template (Markdown)

Use

references/prd-template.md

as the default PRD template and checklist.

Read it before drafting a new PRD.
For updates to an existing PRD, edit only impacted sections and preserve existing checkbox state.
Keep acceptance criteria concrete and verifiable; examples are in the reference file.

Output

Create or reuse
```
tasks/
```
.
Save/update the PRD at the chosen path (prefer existing active
```
tasks/f-##-*.md
```
; otherwise
```
tasks/f-##-<feature-slug>.md
```
).
If the slug or scope is ambiguous, ask the user to confirm before saving.
If
```
tasks/todo.md
```
exists, update it (check the feature only; no PRD path field).
If the PRD introduces durable decisions/constraints, update
```
tasks/memory.md
```
in the same run.
End with a short status block:
- Files changed: list of created/updated files
- Key decisions: any assumptions or choices made (if any)
- Next step: recommended next skill or action

Todo Sync (If

tasks/todo.md

Exists)

Update
```
tasks/todo.md
```
in place; do not reformat the whole file.
Find the matching feature by ID (preferred) or by feature name.
Update the feature checklist item to checked (
```
- [ ]
```
→
```
- [x]
```
). In
```
tasks/todo.md
```
, checked means "PRD exists" (not "built").
Preserve the feature's
```
Type:
```
/
```
Dependencies:
```
lines as-is unless the user explicitly asked to change them.
If the feature is not present in
```
tasks/todo.md
```
, do not create a PRD yet—use
```
new
```
to add the feature first, then return to
```
plan
```
.

Quality Checklist

Before saving, run the "Quality Checklist" in

references/prd-template.md

. At minimum confirm:

existing PRDs were updated in place (no duplicates)
```
tasks/todo.md
```
checkbox was synced when applicable
dependencies and
```
Type:
```
were preserved/updated correctly

plan

NPX Install

Tags

SKILL.md Content

plan

Guardrails

Workflow

Clarifying Questions (Only If Needed)

Example question format

PRD Template (Markdown)

Output

Todo Sync (If
`tasks/todo.md`
Exists)

Quality Checklist