# Crew Scope

> crew-scope: size first, then plan that much

- Skill: `honorboxx/crew-scope` (Agent Skill)
- Install (CLI): `npx skillmds@latest add honorboxx/crew-scope`
- Raw SKILL.md: https://api.skillmd.com/api/skills/honorboxx/crew-scope/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Honorboxx (https://skillmd.com/u/honorboxx)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/honorboxx/crew-scope

---


# crew-scope: size first, then plan that much

The expensive failure isn't messy code; it's building the wrong thing well.
The cheap insurance is proportional: most tasks deserve five lines of plan,
a few deserve none, and a few deserve a real one. Oversized planning is its
own failure (planning theater); this skill picks the size.

## The sizing test

Count the *plausible designs*, not the lines of code:

- **S:** one obvious way to do it, blast radius one or two files. Just do it.
  (A one-line fix in a payment path is NOT S: blast radius outranks size.)
- **M:** one approach, several files; or any task where you paused to think
  "hmm, where should this live?". Write the 5-line mini-plan below, in the
  conversation, before code.
- **L:** two or more genuinely different approaches exist, or the done
  condition is fuzzy, or it touches schema/public API/money. Dispatch
  `crew-planner` (or write a real plan yourself if dispatching is
  unavailable) and get the options question settled before any code.

A second test, for the done condition: if you can't state in one sentence how
you'll *know* the task is finished, it isn't scoped yet. Keep asking "how
will we know?" until that sentence exists. That sentence later becomes the
verification target, so writing it now is not overhead, it's prepayment.

## The 5-line mini-plan (M tasks)

    Goal: <the one-sentence done condition>
    Touches: <files/modules you expect to change>
    Approach: <one sentence, enough for someone to object to>
    Risk: <the thing most likely to bite, and how you'll notice early>
    Non-goal: <the adjacent thing you are deliberately NOT doing>

Thirty seconds to write. Its value is that every line is objection-bait: a
wrong `Touches:` line gets corrected now instead of at review.

## Scope creep: the mid-task rule

"While I'm here" is how an M task becomes an L task nobody approved. When you
notice adjacent work (a refactor begging to happen, a second bug, a missing
test elsewhere): park it in a follow-ups list and finish the scoped task.
The parked list at the end is a *feature* of your report, not an admission of
laziness. Exception: adjacent work that blocks correct completion of the
current task isn't creep. It's discovered scope; resize honestly (M→L) and
say so before continuing.

## Failure modes

| Smell | Correction |
|---|---|
| Mini-plan for renaming a variable | That's planning theater; S tasks skip straight to work |
| "I'll figure out the design as I code" on an L | The design decisions still get made, just silently and worse |
| Questions to the user the codebase can answer | Recon first; ask only what `grep` cannot resolve |
| Done condition = "improve X" | Not a done condition; find the observable |
| Third "while I'm here" this task | Stop; resize or park |