/architect — design decision (ADR)
Goal: a concise, reviewable design with explicit trade-offs — not analysis paralysis.
When to use
Only when the design is non-obvious: a new subsystem, a public interface/data model,
a cross-cutting change, or a refactor with several viable shapes. Skip for routine work.
Do this
- Delegate to the
harness-claude:architect agent with the problem, constraints, and the
existing architecture it must fit.
- Ground it before deciding: name the architecture domain(s) the change touches and pull
the matching cues from
../design/references/architecture-domains.md (API, caching,
cloud-native, message-queue, security). Use context7 for live library/platform docs so
the design doesn't assume capabilities that don't exist.
- Require (each mandatory, not optional):
- recommended approach + interfaces & data model;
- a do-nothing / simplest-possible alternative considered explicitly (the YAGNI gate —
the cheapest thing that could work, and why it's insufficient if you reject it);
- other alternatives considered and why rejected;
- explicit non-functional trade-offs — scale, latency, cost, security — stated, not implied;
- how it degrades under failure (the unhappy path, not just the happy one);
- a quick threat model when the design crosses a trust boundary (handles untrusted input,
auth, secrets, or external calls): ask the four — what can be abused, what happens when it
fails open, who benefits from breaking it, what's the blast radius — and name the trust
boundaries. Skip when nothing untrusted crosses the design;
- risks & mitigations.
- Keep the recommendation decisive — one approach, justified.
Output — ADR
## Context
## Decision (recommended approach)
## Alternatives & why not (incl. the do-nothing / simplest option)
## Non-functional trade-offs (scale · latency · cost · security)
## Interfaces & data model
## Failure & degradation
## Threat model (only if it crosses a trust boundary)
## Risks & mitigations
Save the ADR (session file, or docs/adr/ if the project keeps them).
Exit criterion
A single recommended design with trade-offs stated. Then /harness-claude:implement.
1---2name: architect3description: Make and record an architecture/design decision for non-trivial work — new subsystems, interfaces, data models, or significant refactors. Use when /plan flags a load-bearing decision. Delegates to the harness-claude:architect agent.4---56# /architect — design decision (ADR)78Goal: a concise, reviewable design with explicit trade-offs — not analysis paralysis.910## When to use11Only when the design is non-obvious: a new subsystem, a public interface/data model,12a cross-cutting change, or a refactor with several viable shapes. Skip for routine work.1314## Do this151. **Delegate to the `harness-claude:architect` agent** with the problem, constraints, and the16 existing architecture it must fit.172. **Ground it before deciding:** name the architecture domain(s) the change touches and pull18 the matching cues from `../design/references/architecture-domains.md` (API, caching,19 cloud-native, message-queue, security). Use **context7** for live library/platform docs so20 the design doesn't assume capabilities that don't exist.213. Require (each mandatory, not optional):22 - recommended approach + interfaces & data model;23 - **a do-nothing / simplest-possible alternative** considered explicitly (the YAGNI gate —24 the cheapest thing that could work, and why it's insufficient if you reject it);25 - other alternatives considered and why rejected;26 - **explicit non-functional trade-offs** — scale, latency, cost, security — stated, not implied;27 - **how it degrades under failure** (the unhappy path, not just the happy one);28 - **a quick threat model when the design crosses a trust boundary** (handles untrusted input,29 auth, secrets, or external calls): ask the four — what can be *abused*, what happens when it30 *fails open*, who *benefits* from breaking it, what's the *blast radius* — and name the trust31 boundaries. Skip when nothing untrusted crosses the design;32 - risks & mitigations.334. Keep the recommendation decisive — one approach, justified.3435## Output — ADR36```37## Context38## Decision (recommended approach)39## Alternatives & why not (incl. the do-nothing / simplest option)40## Non-functional trade-offs (scale · latency · cost · security)41## Interfaces & data model42## Failure & degradation43## Threat model (only if it crosses a trust boundary)44## Risks & mitigations45```4647Save the ADR (session file, or `docs/adr/` if the project keeps them).4849## Exit criterion50A single recommended design with trade-offs stated. Then `/harness-claude:implement`.
vasuag09