bonsai
Maintain and groom config files in the current repository. Use when reviewing config health, pruning unused entries, fixing cross-file inconsistencies, applying format changes after tool upgrades, or doing periodic config tidy-up. Not for code quality review of application source.
cross-browser
Use when verifying page rendering or behavior in Safari (WebKit), Firefox, or across multiple browser engines. agent-browser is Chromium-only via CDP; these checks require playwright-cli. Not for Chromium-only verification — use agent-browser there.
decision-log
Persist a decision that has just been settled — the alternatives rejected, the reasoning, the consequences accepted, and the condition for revisiting it — into one database shared by every repository, and retrieve past ones from any of them. Use at the moment a design, architecture, or tooling choice stops being weighed and becomes what will be done, and whenever the alternatives or rationale behind an earlier choice are asked for, including a choice settled while working somewhere else. Not for choices without meaningful trade-offs.
design-conformance
Make new UI look like it belongs in the product that already exists: read the design tokens and components the codebase declares, or where nothing is declared, the conventions its existing screens already follow, and compose within them instead of introducing a fresh aesthetic. Use when adding to or revising a surface that ships beside other screens, and when reviewing UI just written for values invented outside the system. Not for greenfield work where a distinctive, one-off look is the point, not when the brief asks for a new look rather than a consistent one, and not for a codebase that has no UI yet.
devils-advocate
Examine a direction the user has already settled on from both sides at once, each side argued by an independent agent that sees neither the other nor the assessment forming in this conversation. Use before answering someone who presents a course as decided and asks whether to proceed — whether the answer taking shape is agreement or rejection, and above all when the course is the user's own and agreeing would cost nothing — to surface what it rests on and what would settle it. Not for an option still being floated, where no course has been chosen yet. Reports whichever side holds, including when only one does.
external-repo
Use whenever you decide you need to inspect a third-party repo's source on disk — explicit (user pastes a repo URL asking about its contents, "how is X implemented in library Y") or implicit (you yourself proposing mid-conversation to fetch an OSS project to investigate). Managed via ghq for direct Read/Grep. DO NOT USE for one-off doc/raw-file lookups (WebFetch) or work inside the user's own repo.
japanese-writing
Revise Japanese developer-facing technical writing — planning/design docs, meeting materials, issue/PR text, team chat posts — to read plain and accurate: cut overstatement, coined jargon, filler, and blame aimed at people; fix loose paragraphs and notation (spacing around half-width alphanumerics). Use when writing or editing such Japanese prose, including small edits to already-drafted or posted text. Not for English, reference docs, or CLI text.
pr
You MUST invoke this BEFORE running `gh pr create` or `gh pr edit`, and any time the user expresses intent to ship branch work upstream — explicit ("create PR") or implicit ("push this", "ship it", or you yourself proposing to push after completing work). DO NOT USE for leaving inline review comments on an existing PR.
refutation
Verify a finished artifact by dispatching an independent skeptic that never saw it being made, tasked with refuting it, grounding every factual claim in a primary source, and reporting findings with severity and confidence. Invoke before handing over any deliverable that has no automatic falsifier — documents, rules, guidelines, skills, plans, analyses, decisions — above all one produced in the current session. Code already covered by tests, typecheck, or lint has a falsifier; use it there only for claims those checks do not exercise. Not for wording, style, or "does this look OK" passes.
review-prep
Prepare a human reviewer to review someone else's pull request — machine-check verbalizable perspectives with subagents, then hand over a self-contained HTML briefing separating what is safe to skim from what needs the human's design judgment. Strictly read-only against GitHub. Use when the user will themselves review someone else's PR — assigned as reviewer, asking where to start reading before passing judgment, or merely stating they have to review a PR (a bare URL or number with no explicit ask). Not for fully automated review that ends with AI findings, and not for responding to feedback on the user's own PR.
skill-eval
Evaluate and tune an LLM-facing instruction doc — a skill, subagent prompt, or CLAUDE.md/rule addition — by having a fresh subagent execute it blind against frozen scenarios and iterating fixes until improvements plateau. Use right after authoring or substantially revising such a doc, or when a skill misbehaved and instruction-side ambiguity is suspected rather than model failure. Not for typo-level wording changes or personal-taste polish.
socratic
Interview the user one question at a time to turn a half-formed idea into a plan they own. Use when the user muses a tentative idea of their own ("maybe I should X", "I'm thinking of X") rather than asking for a verdict — develop it by questioning, not by recommending; also for pressure-testing a plan decision-by-decision. Not for explicit requests for a recommendation, plain build requests, or rubber-stamping a finished plan.
tdd-first
Pin the expected outcome down as a failing test before writing production code. Use when a change alters observable behavior — new logic, a bug fix, a modified rule. Not for config, docs, or refactors that keep behavior identical.
test-perspectives
Use when writing or expanding tests for code with branching conditions, state transitions, input boundaries, or operational failure modes.