decompose

Files (3)

• SKILL.md
• decomposition-template.md · resources/
• seam-finding.md · resources/

SKILL.md (first lines)

# Decompose

This is a human-facing skill.

Use it when the user has a feature document and wants Darwin to break it into modular, incrementally valuable slices.

## Purpose

Turn a feature document into a decomposition document that is ready for planning and execution.

The result should make these things clear:

- what value lands first
- how the work breaks into seams
- what the walking skeleton is
- which slices can land independently
- what the likely execution seams are
- what should be built next

## Dependencies

- `using-darwin`
- `clarifying-intent`
- `debrief-and-learn`
- `skills/decompose/resources/seam-finding.md`
- `skills/decompose/resources/decomposition-template.md`

## Clarification Rule

Ask at most 3 clarifying questions before presenting the decomposition.

Questions should focus on:

- which feature doc is the source
- what constraints shape delivery
- what kind of incremental value matters most

## Workflow

1. Read the source feature document and clarify anything still ambiguous.
2. Identify the backbone of the user flow or product outcome.
3. Find the major seams in the work: user-facing flows, data boundaries, external integrations, state, UI, or migration paths.
4. Choose the walking skeleton or smallest full vertical slice that proves the feature end to end.
5. Keep anything required to make that walking skeleton understandable and shippable inside the same slice; only split remaining work by variation, workflow branch, business rule, sophistication level, or hardening need when it can truly land later.
6. Before keeping a candidate as its own slice, ask: if this were missing, would the previous slice feel broken, confusing, or obviously incomplete to a user? If yes, merge it back.
7. For a feature that is mostly one tight user flow, prefer 2 slices over 3+ unless there is a clear independent user outcome that lands later.
8. For each meaningful slice, identify the likely execution seams and whether they suggest one agent or multiple agents later.
9. Sequence the slices so each one leaves the product in a better, more useful state.
10. Save the result to `docs/decomposition/<date>-<slug>.md` using the decomposition template.
11. Run a collaborative debrief with the operator about the quality of the decomposition and Darwin's slicing process.
12. Canonize any clear Darwin improvement immediately when it belongs in a skill, prompt, or resource.
13. End with the next best step: move the first slice into `build`, refine the feature doc, or reshape the decomposition.

## Output To The User

Keep the interaction simple:

- a few high-value questions only when needed
- a concise recommendation about the best incremental path
- a saved decomposition document in `docs/decomposition/`
- clear advice on what to build first

## Guardrails

- Do not turn this into implementation planning. The output is slices, not code tasks.
- Do not decompose by technical layer unless the user explicitly wants that.
- Do not produce slices that only make sense after all slices are done.
- Do not create purely technical churn with no visible or testable value unless it unlocks the next slice.
- Do not split off polish, clarity, or basic empty/loading behavior into separate slices when the walking skeleton would feel half-finished without them.
- Do not treat "hardening" as an automatic reason to create another slice; first ask whether that work is part of a complete first user outcome.
- For a single primary user flow, do not exceed 2 slices unless you can name the distinct later user outcome in one sentence.
- Do not skip critique; pressure-test the decomposition before treating it as ready.

From tykowale/darwin, MIT.

More from tykowale/darwin