How to use the Delegating Work Decider agent skill

What the delegating-work skill makes the agent do

The skill is built around one question: how much would a blank slate have to read in before it could do this task correctly? A lot of background means routing the work to an agent that already holds that context. A little means a prompt with light grounding is enough, so a subagent can do it. If you are unsure, the skill says to err toward a real agent or to do the work yourself.

It also warns about the main subagent failure: a subagent starts with no project knowledge, can return a confident but false conclusion, and a poorly contextualized summary looks like an answer. The skill treats that as a reason to match tasks to context, not a reason to stop delegating.

• Decides who does a task: yourself, a subagent, or a context-holding agent
• Explains how to brief an agent depending on the model it runs
• Guides how far to trust a delegated result
• Points to related skills for fan-out mechanics, plan execution, multi-round direction and human decisions

Install the delegating-work skill

Download the ZIP for the delegating-work skill from the page, then unzip it. The skill is a folder containing a SKILL.md file. Place the folder in one of these locations:

For all your projects, put it in ~/.claude/skills/. For a single project, put it in that project's .claude/skills/ folder.

In the Claude apps you can instead upload the ZIP under Settings → Capabilities → Skills.

• Personal install: ~/.claude/skills/
• Project install: .claude/skills/ inside your project
• Claude apps: Settings → Capabilities → Skills, then upload the ZIP

Trigger the skill with natural requests

You do not need a special command. The skill's description tells the agent when to use it, so you trigger it by describing a delegation decision in plain language. Ask the agent who should do a task, whether a subagent is safe for a piece of work, or how to brief another agent.

Requests that fit the skill include deciding whether to hand off a context-heavy change, choosing between a subagent and a reviewer for a lookup, or checking how far to trust a summary a subagent returned.

• "Should a subagent do this, or should the agent that owns this module?"
• "Is this log scan something I can delegate blind, or does it need project context?"
• "How should I brief this agent? I'm not sure which model it's running."
• "A subagent sent back a summary. How much should I trust it?"

Use it for the right kinds of work

The skill sorts work into two groups. Self-contained tasks that can be fully specified in a prompt, such as tracing, research, searching, fetching, summarizing logs or mechanical extraction with citations, suit a subagent. The source's worked example is extracting how four apps implement a UI mechanism with file:line citations, where the requester can check the citations.

Work that needs a lot of prior understanding goes to an agent that holds that context. The source's example is an independent security re-sweep of a rewritten git branch, where knowing which commit range must stay byte-identical is essential.

• Good for a subagent: searching, summarizing, scanning logs, extracting facts with citations
• Good for a context-holder: reviews and changes that depend on project history and constraints
• Practical test: can the requester check the result against something they already know, such as a citation or a count?

Check the model a seat runs and brief it accordingly

How you brief an agent depends on its model. In an OpenRig environment, run rig ps --nodes --json to see the model each seat's spec declares. The field is model, and it shows null if none is declared. A declared model can differ from the one actually running, so if the value is null or you are unsure, ask the seat which model it is running.

Goal-oriented models are built to find their own route, so give them the goal, why it matters, what good looks like, the requirements and the context. Every other model, and any model you cannot identify, does best with smaller pieces, clear steps, clear boundaries and checkable results. Split open-ended work before handing it over.

• Run rig ps --nodes --json and read the model field
• If model is null or unclear, ask the seat which model it runs
• Goal-oriented: give the goal and context, and specify the route only where it matters
• Other models: split the work into smaller steps with clear boundaries

Hand over intent and decide how far to trust results

Whoever does the work, give them the goal, why it matters, the context you hold and where to find more. If you have the requester's own words, pass them on rather than compressing them into steps. Keep exact instructions for the few things that must be exact, and say why.

Trust a delegated result in proportion to whether you can check it. The skill's safety point is that a wrong but plausible answer is dangerous when nobody can detect it, so route those tasks to a context-holder.

• Pass on the goal, reasons, context and sources
• Keep exact instructions only where exactness matters
• Verify results you can check, such as citations you can open