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.
npx agentmods add skills/agent-rig/rig/rig-plannpx skills add agent-rig/rig --skill rig-plangit clone --depth 1 https://github.com/agent-rig/rigWhat 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 | $0.00145 | $0.01553 |
| Opus 5 | $0.00072 | $0.00776 |
| Sonnet 5 | $0.00029 | $0.00311 |
| Haiku 4.5 | $0.00015 | $0.00155 |
Grade A, and why
rig-plan 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 yesterday.
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 — 107 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Spec → backlog planner
Turn a written spec into a reviewed plan and then a materialized backlog.
This is the front door for spec-driven work: you iterate on the spec, rig-plan
proposes the ticket structure, you approve it, and it creates the tickets. It
does not write code or cut branches — execution is /rig-epic and
/rig-task.
Unlike a fixed "epic breakdown," rig-plan is shape-agnostic: it decides, per chunk of the spec, whether the work is an epic, a sprint, or a single ticket.
Configuration
Reads .rig/config.json (defaults in parentheses):
tracker.provider—linear|github|none(none). Where tickets are created.none→ the plan is produced and written to a local file only.tracker.shapeLabels— GitHub-only labels applied at creation (epic/sprint) so a board / dispatcher can tell shapes apart.tracker.board— GitHub Projects v2 identity; when set, created tickets are added to the board via therig-trackeradapter.sourceScope[0]— the codebase area to sanity-check feasibility against.agents.architect(defaultrig-architect) — drives the decomposition.style.guideFile(.claude/STYLE.md) — how the plan and every ticket body it materializes are written.
Delegates ticket creation to /rig-epic (epic chunks), /rig-sprint (sprint
chunks), and /rig-issue (singletons). Hands execution to /rig-epic start /
/rig-task.
Arguments
[spec-file]— path to the spec (default: first ofSPEC.md,specs/prd.md,docs/prd.mdthat exists).--section <name>— plan only one section/milestone (match a heading). Good for "just plan Milestone 0 for now."--yes— skip the approval gate and materialize directly. Use only when the plan is trusted; the default is to STOP for review.
Procedure
-
Resolve config + the spec file. If none is found, ask for the path. Read the whole spec (or just the
--section). -
Decompose — fresh context,
agents.architect. Read the spec againstsourceScope[0]to ground feasibility, then produce a flat list of units and assign each a shape using the interleave test:- epic — several pieces that interleave: one piece's runtime contract
depends on another's incomplete state, or shipping one alone half-migrates
the system. These want a shared integration branch (
/rig-epic). - sprint — several pieces that are independent: each lands on the trunk on
its own (
/rig-sprint). - ticket — a single self-contained unit (
/rig-task//rig-issue).
- epic — several pieces that interleave: one piece's runtime contract
depends on another's incomplete state, or shipping one alone half-migrates
the system. These want a shared integration branch (
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.
- yesterday First seen · 107 lines · 145 tokens per session scan A a08232436adc
rig-plan is a skill published in the GitHub repository agent-rig/rig (2 stars, last pushed 15d ago), licensed MIT. It adds 145 tokens to every session and 1,553 once invoked, about $0.0007 per session on Opus 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 skills, from other repositories
infrastructure-project
Skill for the project management infrastructure module providing multi-project discovery, structure validation, and metadata extraction. Use when discovering active projects, validating project directory structure, or extracting project configuration metadata.
administrative-services-manager
Use when a task needs the judgment of an Administrative Services Manager — evaluating a vendor contract on total cost of ownership rather than price, right-sizing a facilities/admin budget against actual utilization, anticipating where an operational process breaks at the org's next size milestone, or diagnosing why…
architectural-engineering-manager
Use when a task needs the judgment of an Architecture/Engineering firm or department manager — pricing a project fee (lump sum vs. hourly vs. % of construction cost), staffing a project against backlog, evaluating scope creep on a fixed-fee job, managing professional liability exposure, or deciding whether to pursue a…
archivist
Use when a task needs the judgment of an archivist — appraising whether a donated or transferred collection has enduring value, deciding a processing level for a backlog, writing a finding aid, triaging preservation under budget constraints, or resolving a records-restriction question.
deep-research-sprint
Orchestrates the full research sprint: fetch-before-act source warming, Research Scout → Synthesizer → Reviewer → Archivist → Orchestrator commit pipeline. USE FOR: starting a research topic with a formal synthesis deliverable; coordinating the research fleet end-to-end; producing D4 docs/research/.md files with YAML…
prompt-archaeology
Defines the prompt archaeology ritual: systematically mining prior session scratchpads, commit messages, and issue comments to surface decision rationale, failed approaches, and discovered constraints that should be encoded into the substrate. USE FOR: post-sprint review of older session artifacts (.tmp/ scratchpads…