Use when you want a smaller, quicker, cheaper adversarial review of a code change — "a smaller adversarial review", "a quick adversarial review", "a light adversarial review", "adversarial review but don't burn tokens". Runs an 8-reviewer panel (design conformance, whether the design was right, tests, unstated…
Use when you want a hostile, bias-free review of a code change — a PR, the last commit, or local/uncommitted work — that attacks it from many independent angles (conformance to the approved design, whether that design was right in the first place, concurrency, failure injection, input and auth attacks, data integrity…
Use when writing, editing, or reviewing code in any language, and especially before adding or changing a comment or docstring — when tempted to narrate in a comment what was tried first, why an approach was replaced, or what a bug, regression, or review turned up; to restate what the next line already says; to write…
Use when code works but is harder to read, maintain, or extend than it should be — after a feature lands, when review flags complexity, or when you hit deep nesting, long functions, high cyclomatic complexity, functions too tangled to test, two functions that do nearly the same thing, duplicated logic, dead code…
Use when writing any message a person will read — answers, status updates, findings from a review, scan, audit, or debug, plans, recaps, or summaries — especially when the reader may not be able to see the code, files, or systems you are describing, or when another skill (adversarial-review, improve, a code review, a…
Use when writing, editing, or reviewing Go code — any .go file, go.mod, a new package, a function, an error message, a test, a mock, a goroutine — or when asked whether Go code is idiomatic. Also use before answering a question about how something "should" be written in Go.
Use when implementing, integrating, upgrading, debugging, or answering anything involving third-party APIs, libraries, frameworks, CLIs, cloud services, model/provider SDKs, fast-moving product behavior, user requests for latest/current/official behavior, unfamiliar repo docs/specs, errors that may indicate API drift…
Use when long-running or parallel agent work must respect 5-hour and weekly usage limits by checking usage between waves, pausing near the cap, and resuming only when the window is clear.
Use when running a premium model (Claude Fable, Claude Opus, GPT-5.6 Sol, or similar) on codebase-heavy or token-heavy work and the user wants it to orchestrate research, coding, and testing while cheaper subagents (Sonnet, Haiku, Terra, Luna, or similar) do bounded heavy lifting.
Use when the user wants to review an implementation plan visually — "visual plan", "show me the plan in the browser", "render this plan" — or when a plan involves architecture, schema, or API changes worth reviewing before code is written. Writes the plan as markdown and serves it locally (bundled zero-dependency…
Use when the user wants a visual summary of work that was done — "visual recap", "recap this PR/branch/commit visually", "show me what changed in the browser" — for a PR, branch, commit range, or uncommitted changes. Generates a markdown recap grounded in the real diff and serves it locally (bundled zero-dependency…