code-architecture

Use before the first edit of ad-hoc coding work typed straight into a session — loads the always-relevant discipline skills, primes the stack-matched ones by path, and decides in one line whether the task proceeds inline or belongs in the taskmaster pipeline. Not for work that already has a spec or cards.

Use when modeling a business domain — bounded contexts, ubiquitous language, entities vs value objects, aggregates and roots, domain events, context mapping. The DDD toolkit for domains that earn it, not CRUD.

Use when writing or reviewing for readability or simplicity — KISS, DRY, the rule of three, duplication vs over-abstraction, small focused units, few live variables, shallow nesting, meaningful names, no cleverness.

Use before writing any non-trivial code, AFTER the approach shape is settled — which files change, what each new unit owns, the interfaces, where code lives.

Use when shaping system-level structure, before or during implementation — service boundaries, data ownership, scaling, caching, sync vs async integration, single points of failure. Code modules are code-architecture; the domain model is domain-modeling.

Use before claiming work done — success criteria up front, run the verification, show evidence, never assert without output.

Use when designing or reviewing for speculative generality — flags abstractions, config options, flexibility nobody asked for.