team-skills

Supervise another coding agent — Claude Code, Pi, Codex, or OpenCode — running in a tmux pane, separate process, or HTTP port. Use when one agent is observing, nudging, or unblocking another agent's work. Covers all (supervisor × worker) combinations across the four supported agent kinds. Includes a unified `superv` CLI that handles registration, observation, message sending, status classification, notes, and heartbeats.

Launch a three-agent tmux triad with the current agent as supervisor, a Pi worker by default, and a Claude reviewer by default; worker and reviewer start idle and receive task instructions only after explicit supervisor delegation.

Audit a system for accreted complexity — machinery that exists because each change was reasoned about locally and carried forward rather than questioned. Runs two fresh agents of different model families in parallel against the same brief, then synthesizes their independent findings into ranked options. Use after a substantial body of work lands, when a system feels heavier than its purpose, or when a series of individually-reasonable changes has produced something nobody would draw on a blank page. Produces proposals only, never changes.

Write documents — user guides, READMEs, PR descriptions, specs, proposals, commit bodies, code comments — for a reader who has no history. Use when authoring or editing any text a future reader will encounter cold, with no memory of prior versions, abandoned alternatives, or the conversation that produced the text. Triggers include user requests to apply "cold-reader policy", make a document "forward-looking", remove references to "old" / "previous" / "deprecated" / "removed" behavior the reader has no context for, or scrub a document of iteration-history framing.

Maintain active skepticism toward accreted complexity while writing specs and plans, designing systems, implementing changes, and reviewing work. Use when local decisions are cascading into machinery, when a solution feels larger than its purpose, when inherited text or precedent is driving work, during long autonomous plans, or whenever the user asks to use "complexity inoculation."

Merge a branch with another branch (typically `main`) using policy-level reconciliation, not just git's conflict list. Use whenever you run `git merge` or `git rebase` and want to avoid silent post-merge breakage. Treats git-flagged conflicts as one input among many, not the totality of the work.

Write so the reader never has to decode private shorthand. Use when composing any text a reader will parse — chat replies, summaries, PR/commit messages, docs, comments — to avoid inventing one-off jargon, nominalizing a process into an undefined label, or compressing meaning into terms only the writer holds the key to. The reader usually has full conversational and project context; what they lack is the writer's internal naming and compression decisions. Triggers include a reader asking "what do you mean by X", a request to apply "plain-english policy", or the writer catching themselves coining a term mid-conversation and reusing it as if it were shared.

Write or revise pull request descriptions for squash-merge review, focusing on the final net change against the merge base rather than branch history.

Run the default setup workflow: confirm a repo and task, run `triad up` to create the task worktree and launch an idle triad with a recorded state file, read the supervision skills, then wait for explicit delegation before any implementation or review.

Pick the right test invocation when iterating on failures, fixing a bug, or finishing a unit of work. Use whenever you're tempted to run a broad suite (`npm test`, `npm run verify`, `pytest`, `cargo test`, `go test ./...`, full e2e, etc.) to "see what's broken" — that's the failure mode this skill exists to prevent. Triggers: running tests during development, debugging a failing test, choosing how to validate a refactor, deciding whether a slice/PR is ready to land, working on a resource-constrained host where concurrent broad suites OOM.

Build a single-file offline HTML review site for a large pull request, organized by topic with path-specific explanations, embedded diffs, and synchronized file and hierarchy navigation.