feat(pi): add a pi target so rig delegates for real on pi.dev

[pgebheim]

Why

pi ships with no built-in subagents — delegation is an extension you opt into. That left rig's agents.* role indirection with nowhere to resolve on pi, so the personas could only ever be adopted inline. With pi-subagents installed, that same indirection now becomes real delegation with isolated context per role.

Worth noting up front: rig's skills already worked on pi before this PR — pi scans project .agents/skills/ natively, which is exactly where the agents-md target writes them. The gap was the other three layers: personas, invocation, and distribution.

	Before (agents-md)	With the pi target
Skills	auto-discovered	same
Personas	inline adoption	real delegation via the subagent tool
Invocation	"run rig-review"	/rig review find
Updates	re-run onboarding	pi update (package path)

What's in it

pi/agents/*.yml — frontmatter only. The persona body stays in agents/<name>.md, shared by every target; install.sh assembles --- + yml + --- + body at install time. Nothing is duplicated across trees. pi/agents/README.md documents the assembly contract and the full Claude → pi mapping: lowercase tool names (Glob → find), tools with no pi equivalent dropped (WebFetch, WebSearch, TodoWrite, LSP — the bodies already treat LSP as "when available"), no Task for children, and model: opus|sonnet → thinking: high|medium so nothing is pinned to a Claude-only model.

pi/prompts/rig.md — the /rig <skill> [args] dispatcher. This is where the pairing lives. It reads the profile, loads the skill, and applies the delegation contract: children get self-contained tasks, children don't delegate further, read-only roles stay read-only, one writer per worktree, fixed sequences go through workflowScript while convergence loops keep the parent session as controller.

install.sh — a pi adapter with .pi/ auto-detection, plus a latent bug fix found while adding it: the AGENTS.md pointer block was written per target, and since it's replaced wholesale between its markers, a two-target install had the last target silently win. It's now written once, after all adapters, describing every target installed.

package.json — a pi manifest key, so the repo is additionally installable as a pi package (pi install git:github.com/agent-rig/rig) for the skills + dispatcher layer. Git installs run npm install --omit=dev, so the kit's dev toolchain doesn't leak into consumers.

tooling/pi-adapter.test.ts guards the invariant the whole design rests on — every persona has pi frontmatter, name/description byte-identical across trees, only real pi tool names, no subagent for children, architect/reviewer have no write/edit, and the assembly round-trips.

Verification

Against pi 0.84.1 + pi-subagents in a scratch project:

• pi discovered all 11 skills and the /rig template
• pi-subagents parsed all five personas with the expected tools
• a delegation round-trip to rig-reviewer returned
• /rig review find ran the full arc: profile → skill → fresh-context rig-reviewer → REVIEWER.md catalog → scope-reviewer.ts → triaged P0–P3 findings → pointer to /rig review fix
• also checked the manifest-install path, idempotent re-runs (one AGENTS.md block after three runs), and multi-target wording

bun run test: 67 pass, 0 fail.

Testing changed one design decision: the dispatcher originally located skills purely by path, which fails when rig is installed as a pi package (the skill isn't at any of those paths). It now resolves from pi's Agent Skills listing first and falls back to paths.

Notes for the reviewer

• bun run ci fails at HEAD, unrelated to this PR. tooling/prepare-smithers-typecheck.sh needs smithers/agents.example.ts, which isn't tracked (git ls-files smithers is empty). Untouched here; bun run test passes.
• pi-subagents is third-party and on a fast cadence. Rig depends on three things from it — agent definitions in .pi/agents/, the subagent tool, and workflowScript. If a release moves any of those, pi/prompts/rig.md is the single file to update.
• CI templates stay copy-in. GitHub Actions files must physically live in .github/workflows/; no plugin model changes that.

🤖 Generated with Claude Code

https://claude.ai/code/session_01MBaTgFSa8va6PTaFfuSRsz