/decompose

name: decompose
description: Use after the repo is seeded to run the D-000 five-lens decomposition, record persistent schema decisions, define slice one, and start the deltas file. Also use when a stays-ahead decision (decomposition, schema) must be revisited. Do not use for per-slice implementation decisions; those are D-0xx record-gaps raised during implement.

X2 Decompose (D-000)

The one place where the model's whole-solution-space view beats the human's slice-by-slice view, and the decisions a slice cannot cheaply reverse. Everything else stays reversible and waits.

The five-lens session

Decompose the story set under five imposed lenses, one pass each, no code: data flow, failure domain, change frequency, team boundary, trust boundary. Look at what disagrees between the five decompositions; the disagreements are where the real shape decision lives. Choose a shape. Record the choice and the four rejected shapes with reasons as `D-000-decomposition.md` in `docs/decisions/`.

D-000 also records:

• The story set from gate 1. D-000 is the source of truth for it; there is no separate

requirements document (the pilot's turn 8b defect was creating one).

• The recorded product decisions from ideation.
• The persistent schema decisions. Schema is the second stays-ahead asset; approving it is a human

turn, and every later migration is an unconditional human turn, every time.

• The slice-one definition: the smallest slice that ships real user-visible value end to end.

Build scope and design scope are separate rulings: the build is slice-first, the design is whole-product (MET-03); record both.

The launch and exposure pre-flight

Applies when the product will ship to a public audience; rule each concern IN or OUT now, so none of it arrives as ad-hoc directives at the end (record: NS-2, NS-3):

• The estate question: does this greenfield app land inside an existing brand estate (styles,

domains, policies, analytics) that is not greenfield?

• Exposure values: serving domain, sender addresses, public identifiers, entry points. These are

ruled before first use, never assumed; an assumed value propagates into green artifacts and surfaces late.

• Launch concerns: brand chrome and legal pages, discoverability (robots, sitemaps, social and

AI-readability), analytics, abuse pricing, and edge hardening.

Also read the cross-project churn table in the method's `record/negative-space.md`: it names the decision types history says will churn. Pre-decide the pre-decidable ones here; budget the iteration-inherent ones (story refinement, model selection, content voice) instead of fighting them. For the marked chronic churn types, record a confidence and a "wrong-if" line on the decision so reality can trip it later.

The deltas file

Start `deltas.md`: how this project differs from the edition it was seeded from, which the kernel-provenance row names. It grows as the build surfaces differences; it never restates what that edition already says.

Human-turn contract

• Human turns here: the shape choice, schema approval, slice-scope ruling. These are stays-ahead

decisions and are not counted in the per-slice metric.

• Anything presented for a ruling is put in plain language, the owner's own words; method

vocabulary rides alongside, never instead. A ruling made on a summary the owner cannot parse on first read is no ruling at all (P3).

• No MET-07 gate of its own; gate 2 belongs to the design step that follows.

What this skill must NOT produce

• No screens, no prototype, no acceptance criteria, no tests, no code.
• No detailed per-module design; a single-service module is legal and the shape decision is the

module boundary, not the internals.

Next

design, carrying D-000 and the behaviour spec.