git:20260911.37b054b to git:20260923.832673e

---

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

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.

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

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 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 <scope and acceptance revision/source>

Decomposition child features and resources | resources only | none

Because <the signal that decided it>

PF-01 <independently valuable product outcome and BAC-*>

RES-01 <resource>

RES-02 <resource>

TF-01 <independently valuable engineering outcome and TC-*>

RES-03 <resource>

Parent resources (including work not assigned to a child)

RES-04 <resource>

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.