architecture-first

Architecture first — the shape before the first file

Most bad structure is not a bad decision. It is an absent one: code goes where the smallest diff puts it, and the smallest diff is always "next to the last thing". This skill exists to make the layout an explicit, cheap, early decision.

Scope guard — read first

Match the ceremony to the problem. Over-applying this is its own failure mode.

Situation	What this skill asks of you
Script, spike, one file, throwaway	Nothing. Skip.
One module, <500 lines, one reason to change	Name the module and its one job. Stop.
Service / site / API, several concerns	The full pre-code checklist below.
Multiple teams or deployables, shared domain	Checklist + bounded-context map + one ADR per boundary
Multi-stage work or external release prerequisite	Checklist + a small stage map before the first implementation boundary

The one law

Dependencies point inward, toward policy. Business rules must not import the web framework, the ORM, the queue, or the file layout. The reverse is required.

Violating it silently is the failure — a violation that is written down, with the reason and the cost, is a decision. A violation nobody named is erosion.

Practical test: could this module be exercised by a test with no network, no database and no framework? If not, something outer leaked inward.

Pre-code checklist — before the first file

1. Name the modules by reason to change, not by technical layer. queue, billing, catalog — not controllers, models, utils. A module that changes for two unrelated reasons is two modules.
2. Say what each module owns. Especially state: every piece of mutable state has exactly one owning module, and everyone else asks that module. Module-level mutable state shared across features is the coupling that later makes a split expensive.
3. Draw the dependency arrows. Any cycle is a design bug, not a build inconvenience. Any arrow from domain to framework is inverted — fix it with an interface owned by the inner side.
4. Establish the ubiquitous language. One term, one meaning, in code and in speech. If the same word means different things in two places, you have found a bounded context boundary — draw it there.
5. Define the aggregates. What must be consistent in one step, and what may lag. Transaction boundaries follow this, not the other way round.
6. Write one vertical slice end-to-end — UI to store to test — before broadening. A slice that works proves the seams; six half-built layers prove nothing.
7. Record it. One page: modules, ownership, data flow, external systems. Plus one short ADR per decision that was genuinely a choice (context, options, decision, consequences). Both live in git, next to the code.
8. Name the promotion boundaries. When one verified result becomes the input to another stage, name its contract, inputs, output, and invalidation keys before implementation. A missing signer, VM, account, or remote service is a future BLOCKED stage, not a reason to keep reopening already-proven code.