--- name: feature-decomposition description: > Deciding whether a feature should split and, when useful, defining independently valuable Product or Tech child features. During definition, stays at outcomes, owners and acceptance; during engineering delivery preparation, defines implementation resources with stable identifiers, dependencies and validation. Use when several outcomes are bundled together, a small change is being over-split, dependencies or shared work need a breakdown, or progress lacks meaningful units. Does not approve scope or acceptance, write the implementation plan (feature-implementation-plan), track delivery statuses (feature-progress-tracking), or estimate effort (estimation-under-uncertainty). --- # Feature Decomposition ## Purpose Decomposition commonly earns its cost through work that can be **validated independently**, work that must be **ordered** because of a real dependency, and work that will be **shared** across people or sessions. Outside those, a breakdown is a table of contents for a change that would have been easier to read as a diff. Child Product/Tech Features must remain valuable, independently decidable/deliverable, and testable. During delivery preparation, **resources** are what gets implemented, validated and tracked. The calling stage determines which of these outputs is needed. ## Choose the current stage Inspect the request, current definition/analysis revision, accepted scope and any existing breakdown before adding items. Reuse supplied IDs and authorization. If the requested stage is materially unclear, resolve that boundary before creating a delivery breakdown. - **Definition:** decide whether child features earn their cost. Return `PF-*` or `TF-*` with value, beneficiary, independently checkable acceptance, dependencies and the reason for the split, or a concise reason to keep one feature. Product owns Product Feature intent and `BAC-*`; Engineering owns Tech Features and technical criteria. Within a product-owned definition, flag technical enablement for the engineering handoff instead of deciding its solution or `TC-*`. Preserve proposed versus accepted status. Do not create delivery `RES-*`, file tasks or status ledgers merely because `collaborative-feature-definition` invoked this skill. - **Delivery preparation or revision:** use the resource workflow below against the applicable scope and acceptance baseline. Carry criteria from their owning stage; missing or changed acceptance is a question for that owner, not permission to invent intent in the breakdown. ## Delivery resource workflow 1. **Test whether to decompose at all.** If the feature is one resource, say so and produce a one-line list. That is a complete answer. 2. **Produce the resource list first**, from the impact map. Account for each entry as scoped work, validation coverage or an evidenced unchanged dependency. A `READ` entry need not become an edit: link the resource that verifies its relied-on behavior or cite applicable existing evidence. Reuse the current map/scope revision. If none exists, record a minimal source-to-resource mapping for the known work; leave material unknowns open rather than inventing files or scope. 3. **Reuse each resource's `RES-*` identifier or assign one to new work**, with dependencies and validation. Read `references/resource-catalogue.md` for fields, examples and revision rules. A resource with no stated validation is not finished being defined. 4. **Create child features only when the grouping adds an independently valuable outcome.** A Product Feature uses `PF-*`; a Tech Feature uses `TF-*` and names measurable engineering value. 5. **Keep enabling work as resources by default.** A migration, component, infrastructure change, or test harness is `RES-*` unless it independently reduces risk/cost or enables a usable capability with its own acceptance. Do not manufacture a Tech Feature from a phase or layer. 6. **Order the resources** by their dependencies, and say where the order is forced versus merely convenient. Check missing IDs and cycles. A cycle calls for clarifying a shared contract, splitting a producer from its consumer, or merging inseparable work; do not invent a linear order over it. 7. **Say why the shape is what it is** — including "not decomposed, because it is one resource". ## When to decompose | Signal | Decompose? | | ------------------------------------------------------------- | ---------- | | Parts can be validated independently | Yes | | Parts must be ordered because one produces what another needs | Yes | | Parts will be worked by different people or across sessions | Yes | | Part of it could ship without the rest | Yes | | It is one file, one test, one behaviour | No | | The split would be by layer for its own sake | No | | The parts are only separable on paper | No | These signals justify considering a split at the current stage, not a fixed item count. Shared work or a dependency alone does not establish independent child-feature value. Splitting one behavior into controller, service and repository stories usually leaves incomplete outcomes. Layer-specific delivery resources can still be useful for a real handoff or staged contract, with validation and integration prerequisites explicit; they do not become child features merely by being testable. ## Decision rules ```text IF a child cannot state independent product or engineering value and its own acceptance THEN it is not a child feature. At definition, record any enabling need for the owning stage; during delivery breakdown, keep its work as RES-* under the parent. IF a resource has many dependencies THEN verify each necessary input and distinguish implementation, validation and release order. A legitimate integration resource may consume many outputs; count alone does not justify a split. IF two resources always change together and are always validated together THEN consider merging unless ownership, staged compatibility or a real handoff requires separation. IF a resource cannot be validated without another resource existing THEN say so in its validation, and let the order follow from it. IF a resource lacks a path to in-scope impact and acceptance THEN identify the missing mapping or scope decision. One impact entry can justify several resources, and one resource can satisfy several entries; counts are not a scope test. IF a resource is "write the tests" THEN it is misplaced: tests belong to the resource whose behaviour they establish. A separate test resource is legitimate only for shared harness or fixture work. IF preparing a delivery breakdown for a Light feature THEN return one concise resource with its validation when it remains one local outcome. If material dependencies or boundaries emerge, report the changed driver for reclassification; this analysis does not itself authorize implementation. ``` ## Constraints - **Do not split to look thorough.** Three resources implemented and tracked beat eleven resources of which six are one line each. - **Do not decompose by layer by default.** Decompose by behaviour, and let a behaviour touch several layers. - **Every resource traces to the impact map and to scope.** A resource that traces to neither is scope creep with an identifier. - **Do not estimate here.** Sizes and dates are a separate concern with separate discipline. - Preserve supplied Java/framework/runtime and compatibility constraints in each affected resource. Decomposition does not choose upgrades or a new technical baseline. ## Output At definition, return only the child-feature decision and its stage-owned evidence described above. For delivery preparation, use a proportionate version of this breakdown: ```text Baseline Decomposition child features and resources | resources only | none Because PF-01 RES-01 RES-02 TF-01 RES-03 Parent resources (including work not assigned to a child) RES-04 Dependencies RES-02 needs RES-01's column; RES-03 needs RES-02's contract Ready first RES-01, RES-04 (no dependency between them) Then RES-02 -> RES-03; RES-04 may proceed independently ``` Execution consumes resource scope, acceptance, ownership and dependencies together. Independence in the graph permits parallel planning only when shared-file/resource ownership is also resolved. Before handoff, check scope coverage, unique/stable IDs, an acyclic dependency graph and validation for each resource; report unresolved dependencies rather than claiming the breakdown ready. A defined breakdown does not establish accepted scope, implementation or observed validation.