| name | author-shape-bundle |
| description | Author /shape's selection-and-composition bundle for one domain — confirm or prune each capability against the firmed profile + KB, SELECT which of the functionalities /understand already created to build now, place every functionality into a slice or the _deferred bucket, create the persona and USER journey records, the decisions, AND compose the domain's vertical slices. Every slice is a user-facing vertical — it names at least one surface (a screen/view a named persona opens and checks) scaffolded incrementally, and journeys run on those surfaces; a backend-only slice is invalid. Surfaces are NAMED, not designed. Slices reference functionalities by spine id, carry no order/effort/dependencies (that is /roadmap). It does NOT create functionalities or author ICE — /understand did. Under direct-model-write (ADR 026) it writes the per-node RECORDS (each slice, persona, journey, decision, and the _deferred bucket) straight to the live model, with stable ids so re-runs don't duplicate, and emits the spine-delta (capability status flips, the slices index, the refs) as structured data in the manifest — it NEVER writes `_spine.yaml` or the profile. Generative artifact production for the /shape play. |
| version | 0.3.0 |
| user-invocable | false |
| model | opus |
| allowed-tools | Read, Write, Bash, Glob |
author-shape-bundle
Turns a firmed domain — capabilities detailed by /understand (each with its functionalities
already created), profile set — into a selection-and-composition bundle: which
capabilities stay, which are pruned, which existing functionalities to build now, the
personas served, the journeys travelled, the decisions, and the domain's vertical slices.
It reads the profile to judge fit and the KB shelves to ground the selection.
Altitude — the product owner
/vision was the CXO, /understand the product manager. /shape is the product owner: it
decides what gets built and in what shippable shape. It does not detail (that was
/understand) and does not plan order (that is /roadmap). Its output is deliverable
verticals — each a thin slice a user can open and check.
Write discipline — direct-model-write containment split (ADR 026)
Under direct-model-write (standards/rules/direct-model-write.md) there is no draft/ tree.
The split is mandatory:
- You write ONLY the per-node record files — each slice record, each persona record, each
journey record, each decision (ADR) record, and the slice
_deferred.yaml bucket —
straight to the live model under the domain's home at
{product_base}product-os/{domain}/…. Each is its own file with a stable id, so a re-run
overwrites its own record and never duplicates.
- You NEVER write any shared model file: not
_spine.yaml, not profile.yaml. The spine
mutation — the capability status flips, the persona/journey/decision refs attached onto
those capabilities, and the slices index entries — is the job of /shape's deterministic
keyed persist script (persist_shape.py), which merges it into the live spine in place,
keyed to the domain. Node-level containment inside the spine (only the named capabilities
flip, only their status field moves) is the persist's, not yours.
- The spine entries you used to write into a draft
_spine.yaml are now emitted as
structured data in shape-manifest.yaml (a non-model STM artifact) under a
spine_delta block. The keyed persist reads that block and applies it to the live spine.
What it does NOT do
It does not create functionalities and does not author ICE — /understand already
created and detailed every functionality (a spine functionalities entry + a
). /shape SELECTS among those and composes them; it never re-makes them.
It also never writes the profile (the box is /understand's; /shape selects against it) and
never cuts epics (/grill) or plans order (/roadmap).
