Adding a Vendor

Adding a Vendor

Process for adding a new agent CLI to the SpecRoute supported matrix. Adding a vendor is a new column, not a fork. The framework's content (PRDs, specs, prompts, rules) stays unchanged; the runtime shell adapts.

The add-vendor skill walks through this interactively — see .claude/skills/add-vendor/SKILL.md.

Steps

1. Create the runtime layout

runtimes/.<vendor>/
├── README.md                   per-runtime setup steps (model on existing READMEs)
├── settings.template.json      or .toml — whatever the vendor consumes
├── (agents/)                   only if the vendor has an agent primitive
├── (skills/)                   only if the vendor has a skill primitive
├── (commands/ or commands.json) only if the vendor has commands
└── (hooks/)                    if the vendor has hooks

Pattern: only ship the directories the vendor actually consumes. Don't add empty agents/ if the vendor has no agent concept.

2. Add the row to the matrix

The matrix appears in three files. Update all three in lock-step:

• README.md — supported vendor matrix section.
• AGENTS.md — supported vendor matrix section.
• agentic-docs/agent-cli-integrations.md — supported vendor matrix section.

Each row: Vendor | Runtime dir | Root context file | Skills | Agents | Commands | Hooks | MCP config.

Use – for what the vendor doesn't support. If hooks are supported, also update the per-vendor hook depth table in agentic-docs/agent-cli-integrations.md and the event matrix in hooks/README.md.

3. Add the per-vendor rule file

rules/<vendor>-rules.md

Document:

• How the vendor surfaces rules (always-on file, glob-matched, etc.).
• How the shared rules (engineering, code-review, security, documentation) map onto the vendor's format.
• Vendor-specific frontmatter conventions.
• Known limitations vs Claude / Codex.

4. Wire MCP rendering (if supported)

If the vendor consumes MCP servers:

1. Document the vendor's MCP config shape and path.
2. Add runtimes/mcp/render/render_<vendor>.py.
3. Update runtimes/mcp/servers.yaml per-server enabled_for lists to include the new vendor.

See MCP Integration.

5. Update cross-vendor sync (if applicable)

If the vendor shares artifact shapes with Claude or Codex:

• For skills — add its runtime slug to SKILL_VENDORS in tools/sync-skills.py; body-aware sync preserves native frontmatter.
• For agents — do not wire them into this tool. Agent formats diverge across vendors, so maintain the new runtime's agent mirrors explicitly.

If the shapes are genuinely different (Cursor's camelCase hooks.json vs Claude's settings.json hooks block), no sync target; document the asymmetry.

6. Add hook templates

For each vendor that supports hooks:

hooks/<vendor>/
├── hooks.template.json (or .toml or per-hook files)
└── scripts/             optional supporting shell scripts

Use the existing per-vendor templates under hooks/ as the model. Document the event list and blocking semantics in hooks/README.md.

7. Add the delegation shim (if the vendor auto-loads a root file)

If the vendor reads a specific filename at session start (like Claude's CLAUDE.md), add a short delegation shim at the repo root:

# <VENDOR>.md

<Vendor> shim for this repository. Read `AGENTS.md` first; it is the canonical
vendor-neutral source of truth.

## <Vendor>-Specific Context

- (Vendor-specific runtime location, frontmatter quirks, hook config path…)

## Before Publishing

(Vendor-specific sanitization or pre-commit notes.)

Length: 30–50 lines. See Multi-Vendor Context Files.

8. Run /audit

After the changes, run /audit — it checks vendor-matrix consistency across the three files and flags broken cross-references.

Acceptance criteria for "vendor support is complete"

• runtimes/.<vendor>/ exists with a README and the appropriate template files.
• Matrix row is identical across README.md, AGENTS.md, agentic-docs/agent-cli-integrations.md.
• rules/<vendor>-rules.md documents how rules surface.
• If the vendor consumes MCP: renderer exists, servers.yaml per-server enabled_for updated.
• If the vendor has hooks: hooks/<vendor>/ templates exist, event list documented in hooks/README.md.
• If the vendor auto-loads a root file: delegation shim exists at repo root (30–50 lines).
• Per-runtime README walks through setup (rename templates, .gitignore additions, etc.).
• /audit passes.

Owner agent

Vendor onboarding is owned by the runtime-architect agent.

See also

• Vendor Matrix — the contract
• Agent CLI Integrations — how each existing vendor is wired
• Cross-Vendor Sync — keeping things aligned
• Multi-Vendor Context Files — the delegation-shim pattern