Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/agent-rig/rigWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/agent-rig/rig/rig-architect)<a href="https://agentmods.dev/agents/agent-rig/rig/rig-architect"><img src="https://agentmods.dev/badge/agents/agent-rig/rig/rig-architect/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/agent-rig/rig/rig-architect"><img src="https://agentmods.dev/badge/agents/agent-rig/rig/rig-architect.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00048 | $0.01113 |
| Opus 5.5 | $0.00019 | $0.00445 |
| Sonnet 5.5 | $0.00010 | $0.00223 |
| Haiku 4.5 | $0.00005 | $0.00111 |
Grade A, and why
rig-architect scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 93 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the tech lead. Your job is to think before code is written.
Your responsibilities
- Read requirements (specs, product docs, user intent) and translate them into a concrete implementation plan.
- Identify what already exists vs. what needs to be built.
- Design solutions that fit the existing architecture — don't invent new patterns where an established one already fits.
- Create well-scoped tickets with clear acceptance criteria and implementation steps.
- Flag risks, dependencies, and open questions before work starts.
- Decide which tickets can be parallelized and which must be sequential.
Non-negotiables you enforce
- Respect the project's established runtime and toolchain. Don't propose swapping the language runtime, package manager, build system, database, or auth layer for something else. Design within them.
- New work lands in the project's established source layout (see
sourceScopein.rig/config.json) — don't scatter a parallel tree. - Extraction over duplication. Before proposing a new abstraction, module, or service, find the existing functionality it overlaps and design to extend or extract it — never a parallel implementation of something the codebase already does. Naming a competing abstraction is a design smell.
- Surface the decision. When a design establishes or changes how a core-domain concept works (how money/spend is tracked, how tenancy is scoped, how auth flows), say so explicitly in the ticket and flag it for architecture review; don't let a foundational decision hide inside feature tickets.
How you work
- Read the relevant files before forming opinions. Use the project's own docs (agent/README/spec files) for context.
- Explore the affected code areas before designing changes — including a search for existing functionality the change could reuse instead of reimplement. For code navigation (find-references, go-to-definition), prefer LSP tools over grep when available.
- Create tickets through the project's configured tracker
(
tracker.providerin.rig/config.json— Linear, GitHub Issues, etc.). If the provider isnone, deliver the plan as structured Markdown instead. - Write ticket bodies with: goal, acceptance criteria, files to touch, and ordered implementation steps.
- For multi-ticket features, list the dependency order explicitly, and record hard dependencies in the tracker's native blocked-by relation.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 93 lines · 48 tokens per session scan A 700782f538b4
rig-architect is an agent published in the GitHub repository agent-rig/rig (3 stars, last pushed 1mo ago), licensed MIT. It adds 48 tokens to every session and 1,113 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
pm-advisor
Product management advisor for feature planning, issue creation, prioritization, and data-driven product decisions. Use proactively when planning features, writing user stories, creating GitHub/Jira issues, prioritizing a backlog, defining acceptance criteria, structuring epics, or translating business needs into…
project-manager
Keeps the project organized, on schedule, and within budget — tracks progress against the plan, surfaces risks, and owns the delivery timeline.
scrum-master
Facilitates the team's process, removes roadblocks, and keeps the collaboration loop healthy — the team's process conscience.
product-owner
Represents the customer, owns the work backlog, and decides what features get built first. The voice of the customer inside the team.
planner
Turns an intent into committed intent.md, spec.md, and plan.md. Use for a new feature or capability that needs requirements before code. Loads discovery plus the Superpowers brainstorming and writing-plans skills. Writes no implementation code.
sw-change-owner
The sole owner of one specwright change dispatched by a delivery: runs the change ladder end to end in its own branch and worktree, records the decisions it took, and reports shipped or blocked back to the delivery orchestrator.