Architect

---
name: architect
description: Answer build-or-adopt honestly, then design one committed architecture from your own understanding of the problem — stress-tested against the field, its consequences confirmed by the user. A command the user types, for greenfield or architecture-shaping work; standalone, no other skill required.
disable-model-invocation: true
argument-hint: "the system or subsystem to architect"
---

# Architect

Greenfield's territory is the field — the systems that already solved this problem. But the field is not there to be copied: it answers one question and stress-tests another. An architecture assembled from references is a worse copy of something the user could just install.

The concept: **first ask whether to build at all; then design one architecture that is genuinely yours, and let the field attack it.**

- **Build-or-adopt is the first fork, and it belongs to the user.** Study the field honestly enough to answer: does something existing already cover this? If adopting — using, forking, wrapping — covers the need, recommending it is a successful outcome. What justifies building is the **delta** between what the user needs and what exists: name it, put the fork to the user with your recommendation and its price, and if building wins, the delta becomes the design's spine — the part that makes this system worth existing. That is Wardley Mapping's doctrine, applied: build only what differentiates; adopt what's commodity.
- **Design one architecture, committed — never a menu.** A row of reference-flavored options is theater when the user can't tell them apart: they take your recommendation anyway and the ceremony bought nothing. Design from your own understanding of the confirmed problem, at the professional default — a system a senior engineer expects to still be maintaining in three years; the user buys down, never up — and stand behind it. Original decisions need **reasons, not citations**: the sourcing rule binds facts, never thinking — a claim about what an existing system does carries its source; your own design carries its reasoning. And commitment is not momentum: the default stack — the one you'd recommend for *any* problem — was chosen for none. A stack is a fork the user's world decides, so **ask** — the team's hands, the ops that already exist, the load that is real. Every technology in the design then names what selected it, and a choice that can't name its selector is the template designing instead of you.
- **The field attacks the design; it doesn't write it.** Where serious systems converged, diverging needs a stated reason — "every one of them checkpoints transfer state; yours doesn't. Deliberate, or blind?" Where they diverged, real builders disagreed: a fork the user's world decides goes to the user (recommendation attached, price stated); a fork that's pure engineering is yours to decide, with the reason recorded. The stance is Residuality Theory's: stress the design from every direction, and what survives — the residue — is the architecture. A new subsystem landing in an old project has a second attacker: the decisions already recorded there (the `decision-record` skill's index in `.genius/DECIDED.md`, past work, and records that predate this plugin — `docs/adr/`, wherever the repo keeps them) — contradict one and the design either loses or says which decision it overturns and why.
- **The user confirms consequences, not diagrams.** Play the architecture back as behavior — "a transfer dies at 80%: here's what this design does" — until the user says that's what they want. A confirmation of behavior they can evaluate beats approval of boxes and arrows they can't.

Record the study and the decisions where the project keeps its records — a confirmed design a future stranger would re-fight gets its line in the decision index (`decision-record` skill), the rest stays with the work — so the next session reads the record instead of re-deriving it. One study per piece of work: a study already on record is consumed, not redone — research only what it genuinely doesn't cover. The confirmed architecture is the deliverable; what happens next is the user's to type — nothing here advances anything for them.