Decompose Into Backlog

This is the step most teams skip — and the one that costs them the most. You have a set of user stories covering multiple features (comments, validation, auth hardening, maybe search). The temptation is to start building everything at once. The discipline is to decompose into independent units, map their dependencies, pick one ACTIVE unit, and explicitly defer the rest.

A unit is a cohesive group of user stories that can be built, tested, and shipped independently. 'Task comments' is a unit. 'Input validation' is a unit. 'The entire backend' is not a unit — it is a wish.

Claude works best with bounded scope. A single Claude session implementing one well-defined unit produces cleaner code than a session trying to juggle three features at once. Decomposition also enables the artifact chain: each unit gets its own spec, its own architecture decisions, its own tests. When the next unit starts later, it inherits the conventions from the first unit without inheriting the complexity.

When you decompose, don't just list units — map their dependencies. A dependency matrix shows which units can be built in parallel and which have prerequisites. This informs unit selection: you always pick a unit with zero or minimal dependencies first.

In this example, Comments has no hard dependencies — it is the clear first unit and the revenue driver. Validation is independent but lower urgency. Error format depends on validation. Auth is independent but low priority. The matrix plus business context makes the choice obvious.

You have requirements/stories.md with user stories grouped by priority from the previous experiment.

Step 1 — Decompose into units: Ask Claude to decompose the stories into independent units with a dependency matrix.

Tell Claude:

Read the user stories in requirements/stories.md.
Also read requirements/backlog.md if it exists.

If the backlog exists, ADD new units from these stories to the
existing backlog. Do not remove or overwrite existing units.
If the backlog doesn't exist, create it.

Each unit header must follow this EXACT format on a single line:

### `unit-name` — STATUS

Where:
- The heading level is H3 (three hash marks)
- `unit-name` is a kebab-case identifier in backticks (e.g.
  `task-comments`, `error-safety`, `validation-hardening`)
- The separator is an em-dash (—), not a hyphen
- STATUS is one of: DEFERRED, ACTIVE, COMPLETE — uppercase, no
  extra words or qualifiers on the heading line

All new units start with status DEFERRED. Do not put the status
on a separate metadata line — it must be in the header itself so
downstream automation can find it.

For each new unit (under its header):
- 1-sentence description
- Which user stories belong to it
- Dependencies on other units (including existing ones)

Update the dependency matrix to include both existing and new units.

Write to requirements/backlog.md

Observe: Claude groups stories into units and maps dependencies. Check: do the unit boundaries make sense? Does the dependency matrix match what you know about the codebase?

Step 2 — Review and (if needed) reorder: Open requirements/backlog.md. The rest of this workshop walks the task-comments unit through design, implementation, and review. For that to work cleanly, task-comments needs to be the top actionable unit — no blocking prerequisites ahead of it.

Common patterns to watch for:

• Unit 0-style gates (e.g. "credential audit," "security baseline," "test framework setup") that Claude marked as blocking task-comments. These are legitimate in real projects but derail the workshop — the raw sources name them, but they don't produce a user-facing deliverable on their own.
• Validation or error-handling units Claude decided must ship before comments. Stakeholder notes said the opposite — comments first, validation second.

If task-comments already sits at the top with no blocking prerequisites, skip to the next step. Otherwise, tell Claude to reorder.

Tell Claude (only if reordering is needed):

Review requirements/backlog.md. The `task-comments` unit must be
the top actionable unit with no blocking prerequisites.

If task-comments is split into separate API and UI units, merge
them back into a single `task-comments` unit.

For every unit currently listed as a prerequisite of task-comments:
- If it is an audit-only / methodology / setup unit with no user story
  of its own, drop it from the backlog entirely (note the reason in
  the changelog at the bottom).
- If it is a legitimate unit with user stories (e.g. validation,
  error handling), mark it DEFERRED and remove the dependency from
  task-comments.

The planning meeting was explicit: comments ships first because it
drives the Acme renewal. Preserve that ordering.

Rewrite the Units list and Dependency Matrix accordingly. Add a
changelog entry noting what moved and why (including any merged units).

Observe: After this, task-comments should be the first actionable unit with no blocking dependencies. Re-open the file and confirm. If there are still prerequisites, run the prompt again with more specific instructions about which units to drop or defer.

You have reviewed and (if needed) reordered requirements/backlog.md from the previous step. Time to mark the ACTIVE unit.

Step 1 — Mark one unit ACTIVE, defer the rest: Mark exactly ONE unit as ACTIVE. The rest of this workshop walks that single unit through design, implementation, and review end-to-end. Deferred units get picked up later by the Ralph Loop in Phase 4.

In a real project, you'd ask Claude to pick the ACTIVE unit based on dependencies and business value:

Review requirements/backlog.md. Pick exactly ONE unit and change its
header status to ACTIVE. Consider:
- Which unit has the fewest dependencies?
- Which unit drives the most business value?

Every other unit's header status stays DEFERRED.
Preserve the header format exactly: ### `unit-name` — STATUS
Do not add qualifiers after STATUS ("building now", "backlog", etc.).

For the ACTIVE unit, list its specific user stories and acceptance
criteria that are in scope. Everything else is explicitly out of scope.

For this workshop, Phase 2 and Phase 3 are written against task-comments specifically, so use this prompt instead to keep downstream artifacts aligned:

Tell Claude:

Review requirements/backlog.md. Change the `task-comments` unit's
header status to ACTIVE. If you named that unit something else during
decomposition, rename it to `task-comments` now so downstream artifacts
(spec, architecture, tests) line up.

Every other unit's header status stays DEFERRED.
Preserve the header format exactly: ### `unit-name` — STATUS
Do not add qualifiers after STATUS ("building now", "backlog", etc.) —
downstream automation matches the bare status token.

For the ACTIVE unit, list its specific user stories and acceptance
criteria that are in scope. Everything else is explicitly out of scope.

Observe: The backlog now has a clear 'what we are building' vs 'what we are not building yet.' This prevents scope creep in Phase 2 and Phase 3. For the rest of this workshop, you will design and build the ACTIVE unit (task-comments) by hand in Phases 2 and 3. The deferred units get picked up in Phase 4 (Ralph Loop), which builds them autonomously using the same test-first pattern you're about to learn.

Your actual backlog with units, dependency mappings, and active/deferred status. This is your project map for Phases 2-4.

Before moving to Phase 2, verify you have the complete artifact chain:

Every artifact feeds the next phase. The backlog tells Phase 2 which unit to spec first. The stories and backlog together tell Phase 3 what acceptance criteria to turn into tests. Phase 4 reads the backlog to find deferred units and build them autonomously. Nothing lives only in chat.