1
Intent: Deciding What to Build
Deciding what you want precisely enough that done is defined before anything gets built.
Why it matters when agents do the typing
Deciding what to build and what counts as done belongs to the people who need the result and will answer for it. Even an executor that questions the target cannot know what you need better than you do, and no amount of code review fixes a wrong target.
-
Depth: do
Framing the Problem
Working out who has the problem, what outcome would solve it, and what is deliberately out of scope, before any solution is on the table.
A mistake it teaches you to catch: A CSV export button with column pickers built for a request whose real need was the same monthly report sent to an accountant.
-
Core 1
Depth: do
Requirements and Acceptance Criteria
Turning intent into specific, checkable statements of what the software must do and how well, so done has a definition before work starts.
A mistake it teaches you to catch: An export feature marked done that silently omits archived records, because no criterion said whether to include them.
-
Depth: do
Domain Modeling and Invariants
Naming the things in the problem, their lifecycles and the rules that must always hold, so code and tests can enforce them.
A mistake it teaches you to catch: A lifecycle modeled as scattered booleans (isPaid, isShipped, isCancelled) that allows impossible combinations such as shipped but never paid.
-
Depth: do
Design Documents and Decision Records
Writing down the options, the decision and what it costs, so the reasoning outlives the conversation and later readers can follow it.
A mistake it teaches you to catch: A public API field named and shipped during a small bug fix, making the name permanent for every client.