arch-doc — Architecture / ARB Narrative
Produces a single self-contained Markdown document for design discussion: ARB write-ups, design proposals, RFCs. This is a disposable artifact lane — it spawns no agents, generates no machine-readable schemas, runs no ratchet loop and no security review.
Equivalent to /design --doc-only in the full claude_harness_eng_v5 loadout. Use this when running the slim harness-lite loadout, where the full /design skill is intentionally absent.
Usage
/arch-doc # write to docs/architecture/<slug>.md
/arch-doc [path] # write to [path] instead
Flow
Gather context, don't generate it. Read what already exists and is relevant — CONTEXT.md, ADRs, existing source, README.md, prior design docs. If scope or audience is genuinely ambiguous (ARB review? internal proposal? RFC?), ask one or two clarifying questions before writing. Do not run a brainstorming ceremony or a clarification budget — this is a write-up.
Author one document with the sections an architecture review actually needs:
- Context & problem statement — what, why, who it's for.
- Proposed architecture — components, responsibilities, data flows, key interfaces.
- Design decisions & trade-offs — the alternatives weighed and why, not just the chosen option. This is what an ARB scrutinizes most.
- Risks, dependencies, open questions.
- Diagrams — inline Mermaid (sequence / component / deployment) where they clarify.
Write it to the given path, or default to docs/architecture/<slug>.md (create the directory if needed).
Stop. No schemas, no mockups, no agents, no evaluator. Present the document path and a one-paragraph summary. If the design later needs to become shipped code, that is a deliberate decision to switch to the full loadout and enter the pipeline (/spec → /design → /auto).
1---2name: arch-doc3description: Author a standalone architecture / ARB (Architecture Review Board) narrative document. Disposable artifact — no SDLC pipeline, no planner/generator/evaluator, no schemas or mockups.4---56# arch-doc — Architecture / ARB Narrative78Produces a single self-contained Markdown document for design discussion: ARB write-ups, design proposals, RFCs. This is a **disposable artifact** lane — it spawns no agents, generates no machine-readable schemas, runs no ratchet loop and no security review.910> Equivalent to `/design --doc-only` in the full `claude_harness_eng_v5` loadout. Use this when running the slim `harness-lite` loadout, where the full `/design` skill is intentionally absent.1112## Usage1314```15/arch-doc # write to docs/architecture/<slug>.md16/arch-doc [path] # write to [path] instead17```1819## Flow20211. **Gather context, don't generate it.** Read what already exists and is relevant — `CONTEXT.md`, ADRs, existing source, `README.md`, prior design docs. If scope or audience is genuinely ambiguous (ARB review? internal proposal? RFC?), ask one or two clarifying questions before writing. Do not run a brainstorming ceremony or a clarification budget — this is a write-up.22232. **Author one document** with the sections an architecture review actually needs:24 - **Context & problem statement** — what, why, who it's for.25 - **Proposed architecture** — components, responsibilities, data flows, key interfaces.26 - **Design decisions & trade-offs** — the alternatives weighed and why, not just the chosen option. This is what an ARB scrutinizes most.27 - **Risks, dependencies, open questions.**28 - **Diagrams** — inline Mermaid (sequence / component / deployment) where they clarify.29303. **Write it** to the given path, or default to `docs/architecture/<slug>.md` (create the directory if needed).31324. **Stop.** No schemas, no mockups, no agents, no evaluator. Present the document path and a one-paragraph summary. If the design later needs to become shipped code, that is a deliberate decision to switch to the full loadout and enter the pipeline (`/spec` → `/design` → `/auto`).
cwijayasundara