rig-onboard

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:

1. An explicit local path in the invocation args.

2. This skill's own location (.../rig/skills/rig-onboard/) → RIG_DIR is two levels up (the repo root that contains skills/, agents/, ci/).

3. ~/dev/rig, then ~/rig.

4. 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>/… or raw.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. If git isn'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 inspect package.json. Note the monorepo tool (turbo.json, nx.json, workspaces) and package layout (packages/*, apps/*).
• Test command: read package.json scripts (test, test:integration, test:e2e). Detect whether tests boot a database (docker in test setup, testcontainers, a test-setup.ts preload, a Postgres dep).
• VCS: git remote get-url origin → project.repo; git symbolic-ref refs/remotes/origin/HEAD or the default branch → vcs.defaultBranch + vcs.baseRef. Check branch protection / merge queue only if gh is 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, default tracker.provider: "none".
• Review bot: scan recent PRs (if gh available) for a bot reviewer ("codex", "claude"). Otherwise review.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/ or CLAUDE.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 ## Rig pointer block injected into AGENTS.md). If none detected, default to claude-code; if unsure, ask.
  • .pi/ → pi (pi: skills go to .agents/skills/, which pi scans natively; personas to .pi/agents/ in pi-subagents frontmatter; a /rig dispatcher 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/*.md flat-file layout from a pre-.agents/skills/ onboarding — see "Re-running" below.