agentleFS
songjiun10-collabsongjiun10-collab/Senior-thinking-skills/delegate-to-subagents/SKILL.md

delegate-to-subagents

Skill87 starsChanged 33 days agoMITView on GitHub

Decide when to hand work to a subagent instead of doing it yourself, how to brief it, how to run the fix/review loop when something comes back wrong, and how to verify what comes back. Use when a task is big enough to delegate (independent research, a parallelizable slice, a second opinion, a review pass), when running more than one agent, when a subagent's report claims something is finished, or when a review comes back with findings that need fixing. Skip for single-step edits or when no subagent tooling is available. Bundles an optional PreToolUse/PostToolUse hook (scripts/check_dispatch_brief.py) that nudges on two of the mistakes this skill warns about, plus an execution-state dashboard CLI (scripts/execution_manager.py) for a coordinator tracking multiple workers.

  • Deletes or force-pushes

The file

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read whichever file matches the model actually running before applying this skill.

    line 23

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Delegating to Subagents

This skill's substantive guidance (deciding whether to delegate, briefing, coordinating a hierarchy, verifying results, handling blocked/loop cases, and everything else) is calibrated per model. Read the file matching the model you're running as before applying it.

ModelFile
Claude Opus 5.5opus-5-5.md
Claude Fable 5.1fable-5-1.md
Claude Sonnet 5sonnet-5.md
Claude Sonnet 5.5sonnet-5-5.md
Claude Haiku 5.5haiku-5-5.md
OpenAI GPT-6 Astragpt-6-astra.md
OpenAI GPT-6 Solgpt-6-sol.md
OpenAI GPT-6.1 Solgpt-6-1-sol.md
OpenAI GPT-6 Lunagpt-6-luna.md

Read whichever file matches the model actually running before applying this skill.

Running a model not listed above (an older generation, a different model family entirely)? sonnet-5.md carries the fullest general-purpose version of the underlying procedure.

The two pieces below — the dispatch-brief hook and the execution-manager script — are fixed infrastructure tied to specific script paths, not model-dependent guidance, so they live here rather than in the per-model files.

Optional: enforce with a hook

Two of this skill's principles are mechanically catchable — pasting a long conversation summary verbatim, and too many concurrent open dispatches (2-3 is normal, more than that trips it) — scripts/check_dispatch_brief.py detects both right before an Agent call (PreToolUse). By default it only warns, it doesn't block (a default chosen with the assumption this may get installed into projects that aren't your own). To actually block, add the environment variable DELEGATE_HOOK_STRICT=1 to the hook command — the script's header comment documents the exact behavior.

Add to .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Agent",
        "hooks": [
          { "type": "command", "command": "python3 .claude/skills/delegate-to-subagents/scripts/check_dispatch_brief.py" }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Agent",
        "hooks": [
          { "type": "command", "command": "python3 .claude/skills/delegate-to-subagents/scripts/check_dispatch_brief.py" }
        ]
      }
    ]
  }
}

Agent is the built-in dispatch tool's name (some docs/blogs from older Claude Code versions still say Task — if your version predates the rename, use that instead and confirm against your own tool_name in a hook payload). Hook the same script into both PreToolUse and PostToolUse — PostToolUse closes out the specific dispatch that finished, keyed by the call's tool_use_id (hook only one side and open dispatches never get closed). If your skill is installed at a different path, update the command path to match. By default it only warns quietly (visible only in the human-facing transcript) — to make Claude actually react to it (i.e. actually block), prefix the command with DELEGATE_HOOK_STRICT=1 ("command": "DELEGATE_HOOK_STRICT=1 python3 ..."). This hook is example-level enforcement — not a red-team-tested CRITICAL-tier block. For that tier (severity-graded PreToolUse/PostToolUse guards that actually deny rm -rf, force-push, committing to main, etc., by default rather than just warning), see songjiun10-collab/hook — a portable extraction of the same hook framework this line used to point at internally. That plugin covers hard enforcement; this bundle covers the thinking that should prevent the situation from reaching a hook in the first place. If you need something stronger than this example script but lighter than that plugin, use this script as a starting point and adapt it to your project.

Limitation: the hook only counts how many dispatches are open, it doesn't know which files each one touches — two parallel dispatches editing the same file won't trip anything as long as the total count stays under the threshold. Catching that mechanically would mean parsing each brief for the files it intends to touch and cross-checking against the others' — out of scope for this example script; "never let two dispatches edit the same live file" stays something you enforce by reading the briefs yourself.

Optional: track execution state with a script

Acting as a coordinator over several workers means tracking whose status is what — scripts/execution_manager.py is a small CLI for that, so it doesn't have to live in your head or get re-derived from scratch every time you check in:

python3 scripts/execution_manager.py start worker-a "exploring the auth bug"
python3 scripts/execution_manager.py update worker-a blocked "waiting on a prod API key"
python3 scripts/execution_manager.py dashboard
python3 scripts/execution_manager.py clear worker-a

dashboard prints one line per tracked worker — status, elapsed time, and note — and flags any blocked entry that's been stuck past EXECUTION_MANAGER_BLOCKED_WARN_SECONDS (default 1800s). Be precise about what this does and doesn't do: it tracks and displays status; it does not detect that a worker has a problem (something has to call update ... blocked — the worker itself, or you noticing), and it does not decide what to do about a stale one — that's still your judgment call, same as everywhere else in this skill. Read "problem detected → automatic decision → automatic fix" nowhere in this script; it stops at "here's what's stale, go look."

Optionally wire it as a PreToolUse hook on the Agent tool so a stale-blocked warning surfaces automatically right before you dispatch yet another worker, instead of only when you remember to run dashboard yourself:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Agent",
        "hooks": [
          { "type": "command", "command": "python3 .claude/skills/delegate-to-subagents/scripts/execution_manager.py hook" }
        ]
      }
    ]
  }
}

This can sit in the same PreToolUse/Agent matcher block as check_dispatch_brief.py above — Claude Code runs every hook command listed under a matcher, in order. State lives in its own file (.claude/hooks/.execution_manager_state.json by default, override with EXECUTION_MANAGER_STATE_FILE), separate from check_dispatch_brief.py's marker files, so the two don't interfere with each other. Verified with 13 isolated stdin/CLI cases (empty dashboard, start/update/clear, unknown-status rejection, hook mode silent when nothing's stale, hook mode warning once staleness is simulated, PostToolUse and non-Agent calls both silent, malformed stdin fails open, multiple workers with mixed states).

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.