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 plan for that).
Keep features "PRD-sized": one feature = one PRD. If it spans >2 subsystems, >1 UI surface + backend, or >~1 day of work, split it.
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 plan).
Treat memory capture as built-in: if durable decisions are made, update tasks/memory.md in this step instead of deferring to a separate memory pass.

Workflow

Determine intent:
- New project → initialise 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 prioritised 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).
Evaluate memory-worthy outcomes and update tasks/memory.md inline when needed:
- project definition changes
- scope boundaries or constraints that affect future features
- priority decisions with durable rationale
Reply with updated file paths 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

1. 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
- **One-liner**: …
- **Target users**: …
- **Problem**: …
- **Success metrics**: …
- **Constraints** (optional): …
- **Non-goals**: …

## Features

Checkbox meaning: unchecked = PRD not written yet; checked = PRD exists; checked + ~~strikethrough~~ = completed (PRD archived).
Leave unchecked until a PRD exists.
Feature completion is determined by PRDs being archived to `tasks/archive/` and recorded in `tasks/memory.md`; strikethrough here is a derived marker applied during `commit` finalise.

### Features (priority order)
- Higher in the list = higher priority.
- [ ] f-01: <feature name>
  - Type: feat | fix | chore
  - Outcome: <user-visible outcome>
  - In scope: <what ships>
  - Out of scope: <what does not ship>
  - Dependencies: <none> | f-02, f-10

- [ ] f-02: <feature name>
  - Type: feat | fix | chore
  - Outcome: <user-visible outcome>
  - In scope: <what ships>
  - Out of scope: <what does not ship>
  - Dependencies: <none> | f-01

## Open Questions (project-wide only; per-feature questions go under each feature entry)
- Q-1: …

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 prioritised 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".
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)

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. Include minimal bug info:
- Current behaviour: …
- Expected behaviour: …
- Repro steps (if known): …
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 plan (by ID/name): highest priority unchecked feature (checked = PRD exists).
When a PRD is created via plan, ensure the matching feature checkbox is checked in tasks/todo.md.
If you made a durable project decision (scope boundary, constraint, key choice), 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

Quality Checklist

Before finalising tasks/todo.md:

Project section explains what the project is and who it serves.
Feature list is prioritised and reasonably sized (avoid 30 "must-haves").
Feature IDs are unique and stable (no duplicates).
No feature is checked unless its PRD exists.
Each feature has a Type: (feat / fix / chore).
Each feature has a user-visible outcome and explicit scope boundaries.
Dependencies (if any) reference valid feature IDs.
Duplicates/overlaps are merged or clearly distinguished.

new

new