Rig

A copy-in kit of battle-tested Claude Code skills, agents, and CI workflow templates — extracted from a production Bun/monorepo so any project can adopt them. Nothing here is hardwired to the origin project: every project-specific value (test command, issue tracker, base branch, review bot, source layout) is read at runtime from a small project profile you fill in during onboarding.

What's in the box

Layer	Contents	How it's delivered
Skills (skills/)	rig-doctor, rig-debug, rig-spike, rig-tidy, rig-issue, rig-worktree, rig-review (find/fix), rig-proof (find/fix), rig-plan, rig-task, rig-sprint, rig-epic	Copied into <project>/.claude/skills/ (or .agents/skills/ for non-Claude agents — see "Works with your agent" below)
Agents (agents/)	rig-debugger, rig-reviewer, rig-architect, rig-qa, rig-coder	Copied into <project>/.claude/agents/
pi adapter (pi/)	Per-target persona frontmatter (pi/agents/*.yml, assembled onto the shared bodies) + the /rig dispatcher prompt	Copied into <project>/.pi/{agents,prompts}/ — see docs/pi.md
Support docs (templates/)	starter REVIEWER.md (+ REVIEWER.scope-template.md), STYLE.md, label-mapping.md	Copied into <project>/.claude/ (only if absent)
Scripts (scripts/)	setup-worktree.sh, remove-worktree.sh, mint-gh-app-token.sh, scope-reviewer.ts, rig-state.ts, set-session-name.sh (Claude-only)	Copied into <project>/.claude/scripts/
CI templates (ci/)	security-scan, label-pr, image-build, slack-notify, test-gate, test-e2e, and the AI review-bot bundle (review-bot-gate, auto-review-fix, pr-review-labels)	Copied into <project>/.github/workflows/ (see ci/README.md)
Onboarding (skills/rig-onboard/)	The agent-driven installer skill	Run once against a target project

Works with your agent (not just Claude Code)

Skills are just markdown procedures — portable content. Only the placement, format, and invocation differ per agent, so install/onboarding delivers Rig in your agent's own conventions via targets (auto-detected from repo markers):

Target	Delivered as	Covers
claude-code	.claude/skills/<name>/, .claude/agents/, .claude/scripts/ (native skills + subagents)	Claude Code
agents-md	.agents/skills/<name>/ — the standard cross-agent Agent Skills layout, auto-discovered natively (no index needed) — plus .rig/agents/, .rig/scripts/, .rig/REVIEWER.md, .rig/STYLE.md for the pieces the standard doesn't cover, and a minimal ## Rig pointer block injected into AGENTS.md (config + persona adoption)	Codex, Cursor, Gemini CLI, Copilot, Rovo Dev — any agent that scans .agents/skills/ or reads AGENTS.md
pi	.agents/skills/<name>/ (pi scans these natively) + .pi/agents/ personas in pi-subagents frontmatter, a /rig <skill> dispatcher in .pi/prompts/, and npm:pi-subagents registered in .pi/settings.json — see docs/pi.md	pi, with real role delegation instead of inline personas

For agents without subagents, the persona files are adopted inline rather than delegated — the skills reference roles through the agents.* indirection, so they degrade cleanly. Pick targets explicitly with install.sh --target claude-code,agents-md, or let detection choose.

A repo used by Claude Code and another agent installs both targets — but only one physical payload. The skills/agents/scripts live in .agents/ + .rig/, and the .claude/ entries are symlinks at them (Claude Code follows symlinks), so there's a single source of truth to edit instead of two trees that drift. Where symlinks aren't available (Windows without developer mode), .claude/ falls back to its own copy and the install says so.

Simplest onboarding (zero setup)

Open Claude Code in the project you want to onboard and paste one line:

Onboard this repo into Rig by following https://github.com/agent-rig/rig/blob/main/skills/rig-onboard/SKILL.md

Claude fetches that onboarding skill, clones the kit to a temp dir, detects your stack (package manager, test command, base branch, issue tracker, review bot), asks only what it can't infer, writes .rig/config.json, and copies in the skills, agents, and scripts you pick — offering CI workflows separately with the exact secrets each needs. Nothing is installed globally and nothing is committed for you; you review the changes and commit. That's the whole path — no clone, no config editing, no prior install.

Other ways in

• Keep a local copy of the kit (handy if you'll onboard several repos):

  git clone https://github.com/agent-rig/rig ~/dev/rig

  then in your project just say /rig-onboard — it finds ~/dev/rig automatically.
• No agent at all: ~/dev/rig/install.sh <target-project> copies the default set and drops a config stub for you to edit by hand. It auto-detects your agent target(s); override with --target claude-code,agents-md,pi.
• pi users: the kit is also a pi package — pi install git:github.com/agent-rig/rig gets you the skills and the /rig dispatcher globally, updatable with pi update. You still want install.sh --target pi for the per-project pieces; see docs/pi.md.

The project profile

Everything parameterizable is driven by .rig/config.json in your project. Skills read it at runtime — they never hardcode your specifics. See docs/config.md for every knob, rig.schema.json for the machine-readable schema, and rig.config.example.json for a filled-in reference (the origin project's own values).

Design principles

• Config over forking. A parameterizable skill reads .rig/config.json rather than being edited per project. Update the kit → re-run onboarding → get the improvement without re-diffing your local edits.
• Graceful degradation. tracker.provider: "none" strips all ticket steps; review.bot: "none" turns rig-review fix into a local-only loop. A skill never hard-fails because a project doesn't use a given tool.
• CI is copy-in, not a plugin. GitHub Actions files must physically live in .github/workflows/, so they're delivered as parameterized templates with an install guide, not as a runtime dependency.
• Review knowledge compounds where the code is. The review catalog is a tree of REVIEWER.md files (root repo-wide lenses + per-subsystem invariants colocated with the code, mirroring nested AGENTS.md). rig-review resolves the scoped files a diff touches and asserts them as P1s, so a subsystem's hard-won invariants stop getting re-discovered in PR review.
• Long runs keep state on disk, not in the transcript. /rig-task spans seven steps and four delegated agents. /rig-epic run loops that over every child. When the transcript compacts mid-run, the acceptance criteria, the failing assertion, and which review findings are already fixed go with it. So every long skill keeps one small structured document per run under .rig/state/, and scripts/rig-state.ts validates each update outside the model. It rejects unknown keys, wrong types, and impossible states. A size budget stops the document drifting back into a transcript. See docs/state.md.
• Agent output is written for humans. Agents produce a lot of prose — PR bodies, ticket descriptions, review findings, plans, hand-backs — and left alone they write it badly: buried conclusions, passive voice, hedge stacks, filler. Every persona and every prose-emitting skill writes to one house style (templates/STYLE.md, following the Google developer documentation style guide), pointed at by style.guideFile. The core rules are also inlined in each persona, so they hold even when the file is missing.

License

MIT — see LICENSE.