Run a coding task as lead plus crew - the lead model plans, decides and reviews, while cheaper subagents search (scout), implement (builder) and run tests (checker). Use when the user asks to do a task "with the crew", or wants a big model's judgment without paying it to read files and test output.
Installs into .claude/skills of the current project.
Sponsors
SSkills DirectorySkills Directory
Know which skills are safe — weekly.
SSkills DirectorySkills Directory
Is that skill safe to install?
Are you the author of Crew?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/mishgoldenberg-crew)
---
name: crew
description: Run a coding task as lead plus crew - the lead model plans, decides and reviews, while cheaper subagents search (scout), implement (builder) and run tests (checker). Use when the user asks to do a task "with the crew", or wants a big model's judgment without paying it to read files and test output.
argument-hint: <task>
---
# Lead and crew
Task: $ARGUMENTS
You are the lead. Your tokens are the expensive ones, so spend them on judgment: understanding the task, choosing the approach, and reviewing the result. Hand the reading, typing and waiting to the crew, the three subagents in this plugin:
| Agent | Model | Give it |
|---|---|---|
| `fable-crew:scout` | haiku | "Where is X?", "which files touch Y?", "what failed in this log?" Read-only. |
| `fable-crew:builder` | sonnet | One step of your plan: the files, the change, and the check to run. |
| `fable-crew:checker` | haiku | A test, build or lint command. It returns pass/fail and the failing lines only. |
## How to run the task
1. **Scout first.** Before opening files yourself, send the scout (several in parallel for separate questions). Read only the specific lines it points you to.
2. **Plan.** Write a short numbered plan. Each step names its files, the change, and how to check it. If the task is ambiguous in a way that changes the plan, ask the user now.
3. **Build.** Give each step to a builder with everything it needs: it knows nothing except what you write. Run steps that touch different files in parallel; steps that depend on each other go in order.
4. **Check.** Send the checker to run the tests or build. Do not read raw test output yourself.
5. **Review.** Read the final diff yourself (`git diff`). This is the part only you do. If something is wrong, send a builder back with the exact fix, then check again.
6. **Report** to the user: what changed, what the checker saw pass, and anything left open.
## When to do it yourself
Delegating has a cost too: every handoff loses detail. Skip the crew when:
- the change is a few lines in a file you already have open;
- a step needs a design decision, a tricky bug needs real reasoning, or security is involved. That is lead work;
- a builder has failed the same step twice. Take it over.
Never report a step as done on a subagent's word alone when it matters: confirm it in the diff or in the checker's output.