skills/subagent-guide/SKILL.md
MUST invoke before ANY use of the Agent tool — whether the user requests it or you decide independently to delegate work to (parallel) subagents. Applies when spawning subagents, launching background agents, writing prompts for subagents, choosing between foreground and background execution, or deciding how many subagents to spawn. Do not use for agent teams or agent squads.
npx skillsauth add MoonBoi9001/claude-code-cli-tools subagent-guideInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Subagents start with zero context about the current project, problem, or conversation. They cannot ask clarifying questions — they work with what you provide. The quality of their output directly correlates with the completeness of your prompt.
Golden Rule: Include everything a brand new team member would need to understand, independently research, and complete the task. You will not get another opportunity to clarify — the initial prompt must be comprehensive and detailed. If you want the subagent to return specific information after finishing, you must explicitly say so in the prompt.
Before implementing any solution, subagents must evaluate whether the proposed approach makes logical sense in the problem domain. Specifications and issue descriptions may contain flawed assumptions or contradictory requirements.
Sanity Check Directive: If requirements seem economically irrational, technically contradictory, or counterproductive to the stated goal, flag the concern and explain your reasoning rather than blindly implementing. Ask: "Does this actually solve the user's problem, or does it create new ones?"
Domain Awareness: Apply domain knowledge to validate that the solution aligns with how things actually work. A feature that sounds reasonable in isolation may be nonsensical given underlying economic or technical constraints.
Example: If asked to "enforce a higher minimum allocation for zero-signal subgraphs" in a protocol where zero-signal means zero rewards, the agent should flag: "This doesn't make economic sense — why would we force larger allocations to assets that generate no returns?"
When launching multiple agents that modify files in the same repo -- especially agents that create branches, switch branches, or edit overlapping files -- always use isolation: "worktree" on the Agent tool. Without it, concurrent agents share the same working tree and will step on each other: one agent switches branches while another is mid-edit, reverting all uncommitted changes.
Rule: If you are launching 2+ background agents against the same repository and any of them will write files or create branches, every agent must use isolation: "worktree". The only exception is if agents are purely read-only (research/exploration).
A single foreground agent does not need a worktree since it has exclusive access to the working tree.
Always use the latest available Opus model for subagents. Never use Sonnet or Haiku.
Subagents should adhere to all coding standards as defined in CODING-STANDARDS.md unless otherwise specified.
development
Run a deep multi-agent review of a GitHub PR — 6 specialized agents covering architecture, correctness, security, tests, code quality, and integration. ONLY trigger when the user's message contains the explicit phrase 'deep review' (e.g. 'deep review this PR', 'deep review PR #1234', 'do a deep review of 1234', '/deep-review'). Do NOT trigger on bare 'review', 'review this', 'review the PR', 'code review', 'what do you think of this PR', or pasted PR URLs without 'deep review' in the message — those are handled by the lighter /review skill. The literal phrase 'deep review' must appear in the user's message; absence of that phrase means do not invoke this skill.
data-ai
--- name: re-explain description: Re-explain a concept from the ground up when an earlier explanation didn't land. Trigger aggressively whenever the user signals confusion about recent technical content — phrases like "i don't get it", "from scratch", "ground up", "explain again", "this makes no sense", "try again", "you need to work better", "what's X" (where X was something just mentioned), or invoking /re-explain directly. Also trigger on quieter cues like the user re-quoting a phrase from th
development
Load a high-fidelity recap of a prior Claude Code session into the current session's context. The goal is to be LESS lossy than running /compact would be — the user is invoking this skill precisely because /compact discards detail they need. Use this when the user wants to "resume", "pick up", "continue", or "load context from" a previous session — especially a long one (hundreds of thousands of tokens) where actually resuming the session would be prohibitively expensive, or where the session was auto-compacted mid-flow and a lot of detailed work happened after the last compaction that another /compact pass would crush. Also trigger on phrases like "recap the last session", "what was I working on yesterday", "load the prior chat", or "/load-prior-session". The skill extracts via a subagent so the full transcript never enters the current session's context.
development
Convert the most recent code review in the conversation into a grouped numbered checklist (Decisions needed / Fixes / Polish) of issues to fix. Use this skill whenever the user wants to extract, list, summarize, or triage the issues a reviewer raised — including phrasings like "list the issues from that review", "make me a todo from the review", "turn the review into a checklist", "what did the review flag", "summarize that review as a list", "give me every nit from above", or "/review-todo". Trigger especially as a natural follow-up to /review, /deep-review, /security-review, /ultrareview, or any pasted PR / inline review the user wants to act on. The output is a numbered list of every concrete issue the review raised, grouped under bold section headings, with file:line references appended in parentheses, and decision items rendered with a `→` arrow callout below the description posing the specific question — and lettered choices below that when the reviewer named discrete alternatives.