Skip to content
Back to skills

Subagents

ASecurity

Orchestrate subagents to implement code changes. The main thread plans, briefs, dispatches, and reviews. Strictly scoped subagents on Opus write the code. Use for any implementation, audit, or fix that is more than a one-line edit, whenever the user asks for subagents, parallel work, or handing work to agents, even without the word subagent.

  • 2 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 22, 2026
ai-agentsgotestinggitdatabase

Security analysis

A100/100

Pro scans all 4 files and shows the line behind each finding

Scanned October 22, 2026

npx -y skills add skrrt-sh/skills --skill subagents --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Subagents?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Subagents
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/skrrt-sh-subagents/badge)](https://www.skillsdirectory.com/skills/skrrt-sh-subagents)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: subagents
description: Orchestrate subagents to implement code changes. The main thread plans, briefs, dispatches, and reviews. Strictly scoped subagents on Opus write the code. Use for any implementation, audit, or fix that is more than a one-line edit, whenever the user asks for subagents, parallel work, or handing work to agents, even without the word subagent.
---

# Subagents

The main thread plans, briefs, dispatches, and reviews. Subagents write the code.

## Roles

- Main thread: Fable or Opus. On another model, tell the user and offer `/model` before
  dispatching.
- The main thread edits only small review fixes, such as a rename or a missing import. A larger
  fix is a new scope.
- Subagents: `general-purpose` type with `model: "opus"`. Use `sonnet` only if the user asks for a
  cheaper run and the scope is mechanical. An explicit user choice overrides both.
- Never use `fork`. It inherits the main thread's model and context.
- One subagent per scope. Subagents never spawn subagents. At most five running, or the user's
  lower limit. More scopes run in stages.
- Work autonomously. Do not stop to ask; follow the `reporting` skill for questions.
- Inside Herdr (`HERDR_ENV=1`), when scopes need their own checkouts or the user asks for Herdr,
  dispatch with the `herdr-agents` skill instead of `Agent`. All other rules here still apply.

## Process

1. Assess. Fetch first, work from the latest target branch, and check open PRs for overlapping
   work. Send broad reading to an `Explore` subagent on Opus. Check that the plan fits the
   architecture and the codebase's patterns. Correct a wrong plan with the user before briefing.
   Without an outline, draft one and confirm it.
2. Split. A scope is finishable without another scope's in-progress work. Every file belongs to
   exactly one scope. Generated files, such as migrations, lockfiles, and snapshots, belong to one
   scope per stage; regenerate them after integrating. Contracts land in a stage before their
   consumers. Work that cannot be split stays in one scope.
3. Brief. The subagent has none of your context. Brief later stages from what earlier stages
   actually landed: real contracts, signatures, paths. State the goal, the relevant existing code, the
   files it owns, the files off limits, the contracts it builds against, the acceptance command,
   the quality bar, and the report format: files changed, acceptance output, blockers.
4. Dispatch a stage's agents in one message. Then review: read the diff, check file ownership,
   rerun the acceptance commands and the full build, tests, and lint, and check the quality bar.
   Search for an existing component or helper matching each new one; merge duplicates.
   A summary is a claim; the diff is the evidence. Fix small issues yourself. Send larger ones to
   a new subagent with a corrected brief, never back to the one that erred. New work always gets
   a new agent. Before stopping an agent, salvage its diff. Newly found work
   becomes a scope in a later stage. If the evidence shows the approach is wrong, redraw the
   affected scopes, re-brief, and tell the user what changed and why. Only the user changes the
   goal.
5. Finish. Verify every scope item landed and nothing beyond it. Report each stage's result, the
   commands run and their output, your fixes, and what remains. Report failures as failures.

## Quality bar

Put it in every brief. Enforce it in every review.

- Follow the `design-principles`, `testing`, `self-documenting`, and `research` skills.
- UI scopes: also follow the `ui` skills and load the installed design and motion skills, such as
  `emil-design-eng`, `apple-design`, `animate`, and `animate-expo`.
- Never read `.env` files, keys, or process lists. Never use the user's servers, databases,
  devices, or ports; start your own and stop them before reporting.
- Never ask the user. Take the recommended option and list the question in the report.
- Do not touch git. The orchestrator owns commits, branches, and pushes.
- Report honestly: failing as failing, skipped as skipped, guesses as guesses.

Files in this skill

  • SKILL.md4 KB
  • agents/openai.yaml318 B
  • evals/evals.json8.2 KB
  • evals/trigger-evals.json3.4 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.