Which Tasks Need a Claude Code Subagent? Planner

How it works

Subagent Staffing Planner is for the moment you think 'I should make an agent for this' and are not sure which tasks really deserve one. It scores each recurring task and tells you what should stay manual, become a plain skill or become a script.

Phase 1 — List the tasks. Frequency, input size, output needed, side effects and pain for each recurring task you give it. Unknowns stay marked unknown.

Phase 2 — Score. A transparent rubric: frequency, context size, need for isolation, tool risk, parallelism, and whether a script or saved prompt is enough.

Phase 3 — Buckets and anti-patterns. Agent, skill, script or stay manual, plus a check against one-agent-per-task and god-agents with write tools.

Phase 4 — Drafts and table. Read-only .claude/agents/.md drafts with an explicit tools line and a does-not-do list, delegation examples and a final staffing table.

Sample output

Real, unedited output from running this Skill on a sample problem:

## Evidence

| # | Task | Frequency | Input size | Output needed | Side effects | Pain |
|---|---|---|---|---|---|---|
| 1 | Dependency changelog and advisory review (~30 npm packages) | Weekly | Large (30 changelogs and advisories) | Bump decisions | None | An hour a week, lots of noise |
| 2 | Self-review of the diff before a PR | Before each PR | Small (5-15 files) | Bugs, missing tests, debug leftovers | None | unknown |
| 3 | Release: bump, changelog, tag, publish | Every release | Small | Published release | Yes (git tag, npm publish) | Same steps every time |
| 4 | Dead code and unused exports audit (3 packages) | Monthly | Large (whole repo) | List of candidates | None | unknown |
| 5 | prettier, eslint --fix and tests before commit | Daily | Whole repo | Pass/fail | Yes (rewrites files) | unknown |
| 6 | Triage new CLI issues: label, find duplicates, draft first reply | Weekly | Medium (new issues plus history) | Label suggestions, duplicate links, reply drafts | You send replies yourself | unknown |
| 7 | Database schema change decision | Occasional | Varies | A decision | Yes (schema) | Different each time |
| 8 | Find the failing step and likely cause in long CI logs | Whenever CI fails (rate unknown) | Large (long job logs) | Failing step and likely cause | None | Reading long logs |

Frequency or output is unknown for fewer than half the tasks, so I continue.

## Rubric scores

| # | Frequency | Context size | Isolation | Tool risk | Parallelism | Simpler option |
|---|---|---|---|---|---|---|
| 1 | + weekly, same shape | + reads 30 sources, reports a short list | + noise stays out of the chat | + read/web only | + one per package | 0 `npm outdated` and `npm audit` help, but judging changelogs is not scriptable |
| 2 | + each PR | - only 5-15 files, already in main session | - benefits from your intent for the PR | + read-only | 0 | - a saved prompt or skill covers it |
| 3 | + each release | - tiny | - needs your decisions | - publish and tag | - sequential | - a script covers it |
| 4 | 0 monthly | + whole repo | + | + | + per package | - knip or ts-prune style tools do the detection |
| 5 | + daily | - output is pass/fail | - | - rewrites files | - | - hook or script |
| 6 | + weekly | + issues plus duplicate search | + must not send anything | + read-only if labels are suggested, not applied | + per issue | 0 no script judges duplicates or tone |
| 7 | - occasional | 0 | - | - | - | - your judgement |
| 8 | 0 unknown rate | + long logs, short answer | + | + read-only | 0 per failing job | 0 partly (`gh` can extract failed steps) |

## Buckets

- 1: **Agent** (criteria 1, 2, 3, 5).
- 2: **Skill or saved prompt**. Context size is `-`, so it fails the Agent rule.
- 3: **Script or CI job**. Keep the publish trigger manual.
- 4: **Script**. Monthly is not `+` on frequency and the detection is deterministic.
- 5: **Script** (pre-commit hook).
- 6: **Agent** (criteria 1, 2, 3, 5).
- 7: **Stay manual**.
- 8: **Agent, provisional**. It fails the strict rule only because frequency is unknown. Keep it only if CI fails about weekly or more. Otherwise use a saved prompt.

Nothing needs merging: tasks 1, 6 and 8 read different material.

## Anti-pattern check

- "dev-helper" with all tools is a **god-agent with write tools by default**. Drop it. Its overlap with all three new agents would also create duplicate coverage.
- Five of eight tasks are not agents. One agent per task would be a mistake.
- Recurrence alone put tasks 3, 4 and 5 on your list. They are recurring, but a script does them better.
- All drafts are read-only, with an explicit `tools:` line, one job each, no secrets, and no agent-calls-agent.

## Agent drafts

`.claude/agents/dependency-watcher.md`

```markdown
---
name: dependency-watcher
description: Reviews changelogs and security advisories for the npm dependencies you name and recommends bump / hold / urgent.
tools: Read, Grep, Glob, WebFetch, WebSearch
---

You are the dependency reviewer for this project. You receive a request without the surrounding conversation.

## Do
1. Confirm scope: the package list or the package.json / lockfile paths you were given. Note current versions.
2. For each package, read the changelog or release notes between the current and latest version, and check for security advisories.
3. Condense: breaking changes, security fixes and relevant features only. Ignore noise.

## Does not do
- Does not edit, create or delete files.
- Does not run commands that change state, install packages or push anything.
- Does not guess: unknown items are reported as "unverified".
- Does not decide for you; it recommends and cites the source line.

## If context is missing
Say exactly what is missing and stop. Do not assume.

## Report format
Table with columns: package, current, latest, risk (breaking / security / minor / none), action (urgent / bump / hold / skip), one-line reason with source link. Then one line: the verdict and the urgent items first.

.claude/agents/issue-triager.md

---
name: issue-triager
description: Triages new CLI issues: suggests labels, finds likely duplicates, drafts a first reply.
tools: Read, Grep, Glob, <GitHub read-only issue tools; check your Claude Code docs and MCP setup for exact names>
---

You are the issue triager for this project. You receive a request without the surrounding conversation.

## Do
1. Confirm scope: the repository and the issue numbers or date range you were given.
2. Read each issue and search existing issues and the code for duplicates or known causes.
3. Condense: one row per issue, no narration.

## Does not do
- Does not edit, create or delete files.
- Does not apply labels, comment, close or post anything. Replies are drafts only; the owner sends them.
- Does not guess: unknown items are reported as "unverified".
- Does not promise fixes or dates in reply drafts.

## If context is missing
Say exactly what is missing and stop. Do not assume.

## Report format
Table with columns: issue, type (bug / feature / question), suggested labels, duplicate of (or none), confidence. Under it, a draft reply per issue in at most five lines. Then one line: issues needing the owner's attention first.

.claude/agents/ci-failure-analyst.md (provisional, see Buckets)

---
name: ci-failure-analyst
description: Reads CI job logs and reports the actual failing step and the likely cause.
tools: Read, Grep, Glob
---

You are the CI failure analyst for this project. You receive a request without the surrounding conversation.

## Do
1. Confirm scope: the log file paths or pasted logs and the commit or PR you were given.
2. Find the first real failure (not downstream errors), then check the relevant source and config files.
3. Condense: failing step, exact error lines, likely cause.

## Does not do
- Does not edit, create or delete files.
- Does not run commands that change state, install packages or push anything.
- Does not guess: unknown items are reported as "unverified".
- Does not re-run or fix the build; it only diagnoses.

## If context is missing
Say exactly what is missing and stop. Do not assume.

## Report format
At most 6 bullets: job, failing step, key error lines (quoted), likely cause with confidence (high / medium / low), suggested next check. Then one line: flaky, real failure, or unverified.

Delegation examples

• dependency-watcher: "Review the dependencies in package.json of apps/web, apps/api and packages/shared, against the lockfile. Goal: decide this week's bumps. Report urgent security items first." To parallelize, split by package group (one copy per workspace) and have the main session merge the tables and dedupe shared packages.
• issue-triager: "Triage open issues #210-#224 in the CLI repo. Look for duplicates among closed issues too. Draft replies in a friendly, brief tone."
  Parallel option: one copy per issue batch of about five, then the main session checks for duplicates across batches.
• ci-failure-analyst: "The build-and-test job failed on PR #48. The log is saved at ci-logs/run-1234.txt. Find the failing step and cause." For several failed jobs, run one copy per job log.

Staffing table

Recommendation: 3 agents (one provisional), replacing "dev-helper", which you should delete. Declined: #2 (small input, needs your intent, a saved prompt is enough), #3 and #5 (deterministic, use scripts), #4 (monthly, tool-detectable), #7 (your judgement, high cost of error).

Before saving, read each draft's tools: and Does not do list. Saving the files and choosing which tools to grant is your call. Check your Claude Code documentation for exact tool names, especially the GitHub placeholder, and for any model: setting.

## Use cases

- You keep re-explaining the same chore to Claude Code and wonder if it should be an agent
- Cleaning up an over-grown 'helper' agent that has every tool
- Deciding between an agent, a skill, a script or a git hook for a recurring task
- Giving each agent least-privilege tools and a clear report format

## FAQ

**Does it create files for me?** No. It writes drafts in the reply; you decide what to save.

**Is this only for Claude Code?** The drafts use Claude Code's agent format. The scoring works for any agent setup.

**Will it tell me not to build agents?** Often, yes. Tasks that a script, hook or saved prompt does better are marked that way.