Skip to content

architect — guides

Solution architecture as three skills plus one review subagent. architect-design frames a problem, weighs a technical choice, or designs a system without a diagram as the headline. architect-diagram draws the system, flow, state, data model, or deployment topology. architect-review critiques an existing design doc, diagram, RFC, or ADR inline, and its read-only sibling subagent design-reviewer runs the same critique in a forked context that hasn't seen the authoring — the independent pass you reach for after writing a design yourself. They lean on a repo's reference.md — the golden path that says how this codebase is built — when one is present.

All three are knowledge-surface aware. When an internal knowledge surface is reachable — an enterprise-knowledge MCP tool, an internal CLI, an in-repo doc set (public web doesn't count) — architect-design consults it before proposing and names what it drew from, architect-diagram grounds the beyond-repo parts of a document- or update-mode diagram against it, and architect-review flags claims about the world asserted with no cited surface. What can't be grounded becomes a named question or a flag, never a guess.

New here? Establish your repo's reference architecture gives the skills something to design against.

Tutorials

How-to

Reference

Explanation


Installing and upgrading live in ../_shared/.