01 new

Create or update tasks/todo.md as the source of truth for what the project is and what features will be built.

Guardrails

Do not implement code.
Do not write individual feature prds (use 02-plan for that).
Keep features “prd-sized”: one feature = one prd; split anything that feels like an epic.
Prefer a stable todo.md structure; edit in place rather than rewriting.
Write tasks/todo.md so a junior dev (or another AI) can pick it up without extra context.
Do not use Markdown tables (use checklists + bullets).
Do not check feature boxes unless the prd actually exists (typically updated by 02-plan ).

Workflow

Determine intent:
New project → initialize tasks/todo.md .
Add/update features → edit the existing tasks/todo.md .
If tasks/memory.md exists, skim relevant sections (project, key decisions, notes/gotchas) so you don’t conflict with prior decisions.
Ask clarifying questions only when needed (use A/B/C/D options).
Update tasks/todo.md using the template below:
New project: write a crisp Project section + propose an initial prioritized feature list, ordered by priority (highest first).
Add/update: add, merge, re-scope, and/or re-order features.
If adding a new Type: fix item and the user didn’t specify placement, explicitly ask if it should move up the list (priority is determined by list order).
Ensure each feature has clear in-scope vs out-of-scope boundaries and dependencies (if any).
Reply with the updated file path and a short change summary (what you added/changed).

Clarifying Questions (Only If Needed)

Ask up to ~7 high-value questions. Keep them answerable via 1A, 2C, 3B .

Focus on ambiguity around:

target user + primary use case
the problem + desired outcome
constraints (platforms, timeline, integrations)
success metrics / how we know it worked
scope boundaries (what’s explicitly in vs out)
priority order (what should be done first)
whether an item should be Type: feat vs fix vs chore (and where it should sit in priority order)
dependencies between features (by ID)

Example question format

What are we doing right now? A. Start a brand new project B. Add new features to an existing plan C. Refine/re-scope existing planned features D. Other: [describe]

tasks/todo.md Template (Markdown)

If tasks/todo.md does not exist, create it with this structure (fill in details; keep it concise).

TODO: <Project name>

Project

Checkbox meaning: unchecked = prd not written yet; checked = prd exists. Leave unchecked until a prd exists.

Status legend: — = not started | 🔨 = implemented | ✅ = merged

Update Rules (When tasks/todo.md Exists)

Preserve existing content and wording unless the user asks to change it.
Avoid duplicates: if a new feature overlaps an existing one, merge or propose a rename instead of adding a second item.
Keep IDs stable; IDs must be globally unique within tasks/todo.md .
When adding a new feature, use the next ID as (max existing f-##) + 1 (never reuse old IDs).
If duplicate IDs already exist, resolve by renumbering the newer/less-referenced item(s) and updating any Dependencies: references.
Keep the list prioritized top-to-bottom; if placement is unclear, ask where to insert (or add to the bottom).
If a feature depends on another feature, ensure the dependency is listed above it (or explicitly confirm the ordering).
Keep checkbox meaning consistent: checked means “prd exists”.
Keep status indicator consistent: — = not started, 🔨 = implemented, ✅ = merged.
Do not update status indicators; they are managed by 03-implement (🔨 ) and 05-review (✅ after merge).
Ensure each feature entry includes:
a type (feat/fix/chore)
a clear user-visible outcome
in scope / out of scope boundaries
dependencies by ID (if any)
a status indicator (— for new features)
Do not add prd links/paths here; prd: lines are owned by 02-plan .

Feature Writing Guidelines

Prefer feature names as verb phrases (e.g., “Invite teammates”, “Export CSV”).
For fix items, name them clearly (e.g., “Fix ”) and set Type: fix .
For chores, keep them crisp and outcome-oriented (e.g., “Chore: remove dead code”) and set Type: chore .
Ensure each feature has a crisp outcome (what changes for the user).
Avoid implementation tasks (“refactor”, “set up DB”) unless they are truly user-facing requirements.
If a feature is too large, split by user goal or workflow step until each item could reasonably become a single prd.

Output

Create or reuse tasks/ .
Create or update tasks/todo.md .
After updating, suggest the next feature to spec with 02-plan (by ID/name): highest priority unchecked feature (checked = prd exists).
When a prd is created via 02-plan , ensure the matching feature checkbox is checked in tasks/todo.md .
If you made a durable project decision (scope boundary, constraint, key choice), capture it in tasks/memory.md via 06-memory .

Quality Checklist

Before finalizing tasks/todo.md :