ralphctl-abstraction-firstlisted

# Abstraction-First > Concept > > from [Martin Fowler — "Abstraction-First"](https://martinfowler.com/articles/structured-prompt-driven/abstraction-first.html). > Adapted for ralphctl's three phases. The shape of the change comes before the words that describe it. Name the entities, the boundaries, and the seams the change touches **first**; the criteria, tasks, or code that follow are then arguments about that shape, not freeform prose. Skip this and the output reads as a "big blob" — duplicated logic, blurred responsibilities, work that has to be reviewed wholesale rather than incrementally. ## When this applies - **Refine** — name the entities and the boundary of the change before listing acceptance criteria. "Adds a `UserBilling` aggregate that exposes `cancelSubscription`" is the right altitude. "The cancel button must turn red" is too specific to be the spec. - **Plan** — sketch which existing components the change extends, which new ones it introduces, and the seams between them, before splitting into tasks. The task list is then the decomposition of a known shape, not a guess about one. - **Execute** — re-read the task's verification criteria and the surrounding code's existing pattern before opening an editor. The "abstraction" at this altitude is the contract the task already declared; matching it is the job. ## What to do 1. **Name the entities.** Real-world nouns the change talks about — domain objects, aggregates, modules, external systems. I