New Feature

New Feature

When to use

Use this skill when asked to add a new user-facing feature. It ensures you think through all affected layers upfront before writing any code.

What this skill does

This skill is a planning and coordination step. It does NOT contain implementation details — those live in /domain, /read-model, and /controller. This skill ensures you:

1. Identify everything that needs to change
2. Slice the work start-from-the-middle into releasable steps
3. Work test-first within each slice
4. Then delegate implementation to the appropriate skills

Step-by-step process

1. Impact analysis

Before writing any code, search for all consumers of the affected entity's data:

# Find all read models that subscribe to events from the same entity
grep -r "DomainModule::RelatedEvent" apps/rails_application/app/read_models/ -l

# Find all places that store the affected attribute
grep -r "affected_attribute" apps/rails_application/app/read_models/

# Find all views that display it
grep -r "affected_attribute" apps/rails_application/app/views/

For each read model that stores the affected data, ask:

1. Does it subscribe to the creation event for this entity?
2. Does it store or denormalize the attribute being changed?
3. If yes to both: it needs a handler for the new event.

Common patterns requiring multi-read-model updates:

• Renaming — entity names denormalized into other read models
• Price changes — prices snapshotted in order/deal read models
• Status changes — displayed across list views in different read models
• Reassignment — entity associations denormalized in multiple places

2. Produce a plan

List every change needed:

• Domain: new command, event, aggregate method, handler
• Read models: which read models need new event handlers (list each one)
• Controller: which actions change, new routes
• Views: which templates change

Present this plan to the user before proceeding.

3. Slice the work — start from the middle

Reference: "Start from the middle" by Andrzej Krzywda (http://andrzejonsoftware.blogspot.com/2015/09/start-from-middle.html)

Cut the plan into the smallest vertical slices that each keep the whole suite green and are independently deployable. The slices must progress toward the full plan from step 2 — the big picture stays fixed, only the delivery is incremental.

Finding the middle: the middle is the riskiest or most essential decision of the feature — usually the new domain behavior (commands, events, the rule being enforced). The edges — real third-party adapters, imports, forms, UI polish — come last or get faked.

Slicing rules:

• Each slice leaves the app releasable: green tests, no half-wired user-facing behavior. Dormant code is fine — an event handler or process manager nobody triggers yet is a free feature toggle in an event-driven system.
• Fake the risky dependency first, integrate it later. A fake gateway or fake client is a legitimate slice; the real adapter is a later slice.
• Default slice order: domain building blocks (dormant) → coordination (process managers, still dormant) → adapters/infrastructure → the final slice flips the user-visible behavior (controller/view wiring).
• One slice = one commit (see /commit). After each slice: run the tests, commit, present to the user for acceptance, and only then start the next slice.

Present the slice list to the user before implementing.