tddworks/claude-skills/feature-lifecycle

Feature Lifecycle

One skill, eight focused phases. Each phase tells the agent exactly what to do for that step — inputs, steps, outputs, and a gate to know it's done.

1. Discovery        → what already exists, what the user means
2. Domain design    → ASCII architecture + naming + user approval
3. Domain TDD       → value tests + aggregate tests + protocol + impl class (Red → Green)
4. Composition      → plug the aggregate onto parent + facade forwarders
5. Infrastructure   → port conformance + push routing + wire format
6. Views            → SwiftUI bind to the facade; no ViewModel layer
7. Docs             → feature doc + aggregate audit + visual artifacts
8. Verify           → pre-commit checklist + tests + build

The phases are sequential. Don't skip ahead. If a phase's gate isn't met, go back.

Which sub-guide to load

Load only the reference for the phase you're in. Don't read the full set up front.

The core pattern (the thing every phase serves)

// 1. Domain noun — protocol
@MainActor @Mockable
public protocol <Aggregate>: Observable {
    var items: [<Value>] { get }
    // ... rich computed queries + business-intent commands + apply/upsert/remove
}
 
// 2. Concrete implementation class
@Observable @MainActor
public final class <AggregateImpl>: <Aggregate> {
    public init(port: (any <AggregatePort>)? = nil) { … }
}
 
// 3. Narrow internal port (infra seam)
@Mockable
public protocol <AggregatePort>: Sendable {
    // async throws methods the infra client / DB / API implements
}

Every phase assumes this shape. Deviations (protocol-less classes, legacy xxxBackend glue, role protocols named as collections) are smells — see `references/02-domain-design.md` for the naming playbook.

When in doubt

• Names feel clunky? Read them out loud. If a non-engineer wouldn't say it, rename.
• Tests hard to write? The aggregate is coupled to too much. Pull dependencies behind a narrow port.
• Composition root keeps growing methods? Push them down to the owning aggregate. The root is a facade, not a coordinator.
• Views casting `as? <concrete impl>`? Protocol surface too minimal. Grow it.
• User pushes back on a name? Pushback is signal. Re-derive from first principles — don't patch with another loaded word.

The anti-patterns (from most-costly, in order)

1. Jumping to code without Phase 1–2. You'll build the wrong shape and have to undo it.
2. Domain as setters only — no rich behavior. Logic ends up scattered across views and infra.
3. `XxxBackend`, `XxxRegistry`, `XxxManager`, `XxxService`. Infrastructure words in the domain.
4. Coordinator methods on the composition root. Cross-aggregate orchestration lives on the aggregate that owns the triggering state, or propagates via @Observable reactions.
5. Views touching `@Observable` indirection (e.g. root.something?.child?.more). Expose a facade on the root; never leak composition detail to views.
6. Interaction-based tests (verify(mock).method.called(...)). This skill uses Chicago-school state/return-value tests only.
7. Ship-first, doc-after. The feature doc (Phase 7) captures why; write it before memory decays.

Load the next sub-guide when you're ready for the phase. One at a time.