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-onboardnpx skills add agent-rig/rig --skill rig-onboardgit 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.00067 | $0.03223 |
| Opus 5 | $0.00034 | $0.01612 |
| Sonnet 5 | $0.00013 | $0.00645 |
| Haiku 4.5 | $0.00007 | $0.00322 |
Grade A, and why
rig-onboard 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 2d 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 — 210 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Rig onboarding
You are onboarding the current working project (the "target") into Rig. Your job is to detect what the project is, agree a project profile with the user, copy in the pieces they want, and leave them with a working, documented setup. Be interactive but efficient — detect aggressively, ask only what you cannot infer.
0. Locate the kit (RIG_DIR)
The kit lives in a directory (RIG_DIR) separate from the target project — you
copy files out of it. Resolve RIG_DIR in this order:
-
An explicit local path in the invocation args.
-
This skill's own location (
.../rig/skills/rig-onboard/) →RIG_DIRis two levels up (the repo root that containsskills/,agents/,ci/). -
~/dev/rig, then~/rig. -
Remote (the zero-setup path). If none of the above exist — which is the case when the user just pointed you at a GitHub URL for this skill — clone the kit to a temp dir and use that as
RIG_DIR:RIG_DIR="$(mktemp -d)/rig" git clone --depth 1 <RIG_REPO_URL> "$RIG_DIR"Derive
<RIG_REPO_URL>from the URL you were given: strip any/blob/<branch>/…orraw.githubusercontent.com/…suffix back to the repo root (e.g.https://github.com/agent-rig/rig). Cloning is strongly preferred over fetching files one-by-one — the kit is ~40 small text files and a shallow clone grabs them all at once. Ifgitisn't available, fall back to fetching individual raw files as you need them.
Then confirm the resolved RIG_DIR with the user before copying anything.
Never copy a file onto itself — if the target project is the kit, stop and say so.
1. Detect the stack (no questions yet)
Read, don't ask. Gather:
- Runtime / package manager: presence of
bun.lockb/bunfig.toml→ bun;pnpm-lock.yaml→ pnpm;yarn.lock→ yarn;package-lock.json→ npm; else inspectpackage.json. Note the monorepo tool (turbo.json,nx.json, workspaces) and package layout (packages/*,apps/*). - Test command: read
package.jsonscripts (test,test:integration,test:e2e). Detect whether tests boot a database (docker in test setup,testcontainers, atest-setup.tspreload, a Postgres dep). - VCS:
git remote get-url origin→project.repo;git symbolic-ref refs/remotes/origin/HEADor the default branch →vcs.defaultBranch+vcs.baseRef. Check branch protection / merge queue only ifghis available. - Tracker: is a Linear MCP server connected? Do existing branch names /
recent PR titles carry a ticket prefix (e.g.
ABC-123)? If neither, defaulttracker.provider: "none". - Review bot: scan recent PRs (if
ghavailable) for a bot reviewer ("codex", "claude"). Otherwisereview.bot: "none". - Agent(s) / delivery target: which coding agent does this project use? Map
from repo markers to delivery targets (may be more than one):
.claude/orCLAUDE.md→claude-code(native:.claude/skills/,.claude/agents/).AGENTS.md,.agents/,.cursor/,.github/copilot-instructions.md,GEMINI.md, or.windsurf/→agents-md(universal: skills land in.agents/skills/<name>/— the standard cross-agent "Agent Skills" layout that Codex, Cursor, Gemini CLI, Copilot, and Rovo Dev auto-discover natively, so no per-skill index file is needed; agents/scripts/review patterns stay under.rig/, the same home as the config profile, since nothing else standardizes those; plus a minimal## Rigpointer block injected intoAGENTS.md). If none detected, default toclaude-code; if unsure, ask..pi/→pi(pi: skills go to.agents/skills/, which pi scans natively; personas to.pi/agents/inpi-subagentsfrontmatter; a/rigdispatcher to.pi/prompts/). Detect alongside the others — a repo worked on from both Claude Code and pi wants both targets.
- Existing
.claude/or.agents/skills/: note any skills/agents already present so you can warn before overwriting. Also check for a legacy.rig/skills/*.mdflat-file layout from a pre-.agents/skills/onboarding — see "Re-running" below.
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.
- 2d ago First seen · 210 lines · 67 tokens per session scan A 8ca976c89830
rig-onboard is a skill published in the GitHub repository agent-rig/rig (2 stars, last pushed 16d ago), licensed MIT. It adds 67 tokens to every session and 3,223 once invoked, about $0.0003 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
hooksmith
Use when designing or reviewing safe Grok Build hooks for linting, tests, formatting, notifications, command guards, lifecycle automation, or project hook trust decisions.
github-actions
GitHub Actions workflow review, scaffolding, and security hardening. Use when user says 'review my workflow', 'check my actions', 'scaffold a workflow', 'is my CI correct', 'pin actions', 'OIDC to AWS', or when working in .github/workflows/.yml files.
ci
GitLab CI/CD pipeline review and scaffolding for Terraform and Helm/EKS deployments, including individual stages, jobs, manual gates on prod stages, and pipeline credentials. Use when user says 'review my pipeline', 'check my gitlab-ci', 'scaffold a pipeline', 'is my CI correct', 'is my pipeline gated before prod'…
e2e-failure-paths
Validate pipeline behavior under failure conditions. Use when simulating test failures, SAST failures, build failures, validating no GitOps update occurs, or checking error propagation.
e2e-happy-path
Validate the full pipeline success path from commit to deployment. Use when triggering a full CI pipeline run, validating build artifacts, GitOps update, reconciliation, deployment, or running smoke tests.
pipeline-execution-validation
Validate that the CI pipeline executes all required stages correctly. Use when validating type-check, lint, SAST, build, test, and release stages, or validating artifact generation.