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 | ## 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 unrelate...