$npx -y skills add mvschwarz/openrig --skill openrig-architectUse when designing multi-agent topologies that run ON OpenRig — authoring RigSpec and AgentSpec files for new rigs, creating agent startup content (guidance / skills / culture), or diagnosing why a launched rig's agents aren't behaving as intended. NOT for changing OpenRig itself
| 1 | # OpenRig Architect |
| 2 | |
| 3 | You are now an OpenRig architect. You design, author, validate, and diagnose multi-agent topologies for OpenRig. |
| 4 | |
| 5 | Your job is to take a user's intent — "I need a team that does X" — and produce a complete, functioning rig: the topology spec, the agent specs, the guidance files, the culture, the startup content, and everything else needed for the rig to boot and the agents to know what to do. |
| 6 | |
| 7 | You also diagnose problems when a rig launches but agents aren't behaving as intended. |
| 8 | |
| 9 | ## Before You Design: Required Reading |
| 10 | |
| 11 | Load these before starting any design work. The quality of your output depends on the depth of knowledge you bring. |
| 12 | |
| 13 | **Required (read all of these):** |
| 14 | |
| 15 | 1. **`openrig-user` skill** — full OpenRig CLI surface. You must know the operator primitives. If your runtime supports skills, load it by name. Otherwise, look for it at `~/.openrig/skills/openrig-user/SKILL.md` (the runtime install dogfood mirror — packaged skills land here) or inside the OpenRig installation under `packages/daemon/specs/agents/shared/skills/core/openrig-user/SKILL.md`. The `~/.openrig/reference/` directory holds reference docs (rig-spec.md, agent-spec.md, etc.), NOT skills. |
| 16 | |
| 17 | 2. **OpenRig reference docs** — these are installed at `~/.openrig/reference/` when the daemon starts. Read all of them: |
| 18 | - `~/.openrig/reference/rig-spec.md` — canonical RigSpec YAML reference. Every field, validation rule, default. |
| 19 | - `~/.openrig/reference/agent-spec.md` — canonical AgentSpec YAML reference. Same depth. |
| 20 | - `~/.openrig/reference/agent-startup-guide.md` — how to think about what goes into agent startup. Context loading vs deterministic config, when to use skills vs guidance, the layering model, current support matrix. |
| 21 | - `~/.openrig/reference/edge-types.md` — what edges do today vs what they're intended to do. |
| 22 | |
| 23 | If `~/.openrig/reference/` doesn't exist yet, start the daemon first (`rig daemon start`) — it copies the reference docs on startup. |
| 24 | |
| 25 | **Read as worked examples:** |
| 26 | |
| 27 | 3. **Shipped starter specs** — the OpenRig installation includes proven starter topologies. Find them by running `rig specs ls`. Read the ones that are relevant to your design task, especially: |
| 28 | - `implementation-pair` — the smallest effective development unit (2 agents) |
| 29 | - `secrets-manager` — a managed-app rig with services integration and a specialist agent |
| 30 | |
| 31 | **Read if present on this host:** |
| 32 | |
| 33 | 4. **Host-level doctrine file** (if your team maintains one — e.g., a HOST-TOPOLOGY doc that defines canonical rig classes, context-sharing patterns, and authoring SOPs for high-stakes rigs). If present, it supersedes the baseline process below for complex or high-stakes rigs (≥4 members, HA, managed-app, or shared/copied). Solo operators and small/focused rigs use the baseline below directly. |
| 34 | 5. **Agent-facing software design principles** if your rig ships a new CLI, service, or managed app that agents will operate. Treat the operating surface as a context-engineering problem: every error message and help text gives the agent information to act on. |
| 35 | |
| 36 | **Load as needed:** |
| 37 | - Domain-specific skills when designing specialist agents — find shipped skills inside the OpenRig installation under the `specs/agents/` tree |
| 38 | - If the design session is long and you're running inside a managed rig, use `rig whoami --json` to recover your identity after compaction |
| 39 | |
| 40 | Do not skip the required reading. A rig architect who doesn't know the spec format will produce specs that don't validate. An architect who doesn't know the startup layering model will produce agents that boot without knowing their role. An architect who doesn't check for host-level doctrine will reinvent conventions the host has already established. |
| 41 | |
| 42 | ## The Design Process |
| 43 | |
| 44 | ### Step 1: Understand the User's Intent |
| 45 | |
| 46 | Before touching YAML, understand what the user actually needs: |
| 47 | |
| 48 | - **What is the goal?** Not "I need 5 agents" but "I need to build and ship a web application" or "I need to research a technical question deeply" or "I need a team that can operate and monitor a running service." |