architecture

Related Skills

This skill owns structural planning — how the system is organised. Two neighbouring concerns are different kinds of problem and stay separate:

• Defining what the domain concepts are (Entity, Value Object, Aggregate, Domain Event)? → domain-modeling. Structure follows the model: context and module boundaries align with aggregate boundaries, so let domain-modeling settle those first.
• Solving a recurring local problem with a named pattern (Strategy, Adapter, Observer…)? → design-patterns.
• Moving code between structures safely? → refactoring for the mechanical steps.
• A trust boundary in the structure? → security + schema.

A design-forces memo, when one exists, is the input to this skill: it carries the force signals that decide whether and what to structure. Principles (KISS, SOLID, DRY, YAGNI, fail-fast) are how every structure is implemented, never something a structure replaces.

The default is no extra structure

Start from the position that the feature needs no architectural ceremony beyond what the framework already gives you. A framework is itself an architecture; following its grain plainly is a legitimate, often correct, answer. Structure earns its place only when forces make the absence of it more expensive than the cost of adding it.

Resist mapping a framework to a named style by reflex ("Rails, so DCI"; "Spring, so layers"). That is mechanical correspondence wearing a different hat — it bypasses the judgement that makes structure fit. The framework's nature is one input to the force judgement, not a lookup that pre-decides the answer.

When this skill applies — two modes

Mode A — follow the recorded structure (cheap path)

docs/architecture.md is a deliberately cheap, maintainable signal. When it exists and covers the area being touched:

1. Read its style declaration and Patterns section.
2. Apply the recorded structure as-is.
3. Re-open the decision only if a recorded revisit trigger has fired.