scope
/scope
Cut an approved brief or plan into slices that can each be built and verified on their own. Use when a plan is agreed and the next question is what order to build it in, or when a task feels too big to hand over in one go.
- Author
- nirkaufman ↗
- Repository
- claude-code-workshop-assets ↗
- Licence
- MIT
- Last repository change
- 08.11.2026
Assessment and security
- Files in this package
- 1
- Scripts
- 0
- HTML comments
- 0
- URLs in SKILL.md
- 0
No signals detected. Repository changed on 08.11.2026, without references to retired models or APIs.
MIT, open: use and modify while retaining author attribution.
What it does and when to use it
Cut an approved brief or plan into slices that can each be built and verified on their own. Use when a plan is agreed and the next question is what order to build it in, or when a task feels too big to hand over in one go.
Arguments
/scope <path-to-brief-or-plan>
Original author description
Cut an approved brief or plan into slices that can each be built and verified on their own. Use when a plan is agreed and the next question is what order to build it in, or when a task feels too big to hand over in one go.
How it works
- The document
- What a slice is
- What to produce
- Rules
SKILL.md preview
--- name: scope description: Cut an approved brief or plan into slices that can each be built and verified on their own. Use when a plan is agreed and the next question is what order to build it in, or when a task feels too big to hand over in one go. argument-hint: <path-to-brief-or-plan> disable-model-invocation: true allowed-tools: Read Glob Grep Bash(cat *) --- # Scope ## The document ```! cat "$0" 2>/dev/null || echo "NO FILE READ: argument was '$0'" ``` If the block above says NO FILE READ, stop and ask for the path. ## What a slice is A slice is **one thing you can look at and judge.** Not a layer, not a file, not a phase. Three tests. A slice that fails any of them is not a slice: 1. **Visible.** When it is done, something observable changed — a screen renders, a command prints, a request returns. "Set up the data model" fails this. "The table shows three hardcoded rows" passes. 2. **Verifiable without the next slice.** You can confirm it works before building anything else. If confirming it requires slice 4, it belongs with slice 4. 3. **Revertible.** It is one commit. If it goes wrong, throwing it away loses an hour, not a day. ## What to produce **A numbered list of slices, in build order.** Aim for 3 to 6. More than 8 means the brief is too big and you should say so instead of slicing it. For each slice: - **What changes** — in one line, in terms of behaviour, not files. - **How to verify** — the exact thing a human does with their own hands. A command to run, a URL to open, a click. Not "check that it works" and not "the tests pass". - **What it deliberately does not do yet** — one line. This is what keeps the slice small when you are mid-build and tempted. Then, separately: **The riskiest slice.** Name the one most likely to go wrong or take twice its estimate, and say why. If it is not slice 1, say whether it should be — doing the risky part first means finding out early, while there is still time to change the plan. **What is not in any slice.** Anything in the brief you could not place. That is either scope you forgot or scope that should be cut, and either way the user needs to see it now rather than discover it at the end. ## Rules - Do not implement anything. This produces a build order, nothing else. - Do not invent requirements the document does not contain. If a slice needs a decision that has not been made, say so and stop at that slice. - Order for **early feedback**, not for architectural tidiness. Building the data layer first is tidy and tells you nothing for an hour.
Versions
| Repository | Score | Licence |
|---|---|---|
| This page · nirkaufman/claude-code-workshop-assets | 100 | MIT |
| crisandrews/clawcode | 100 | MIT |
| camoa/claude-skills | 100 | MIT |
| alexzio00/sovereign-skills | 100 | MIT |
| ccplugins/awesome-claude-code-plugins | 100 | Apache-2.0 |
| ialameh/sift-coder | 100 | MIT |
| lilly-logic-labs/lll-skills | 90 | MIT |
| technicalpickles/pickled-claude-plugins | 90 | MIT |
| suboss87/FDEOps | 90 | MIT |
Database snapshot: 13.11.2026 · package version 4531c7d42856 (SHA-256 digest of the entire package)
Downloads in the last 30 days: 0 · ranking
Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.
Similar skills
- 100plan-feature
Use when the user says "plan a feature", "design this", "how should we build", or before writing code for any non-trivial feature. Produces an approved task breakdown before implementation begins — plan first, build second. - 100dx-split-issue
Use when an issue that already exists turns out to be too big to deliver in one pull request, for example "this story is too large", "break #142 into pieces", "split this issue up", or when `dx-implement-issue` stops and reports that a plan covers two unrelated capabilities.… - 90implementation-plan
Breaks multi-step or cross-file work into small, independently verifiable slices with exact files, steps, commands, and risks, without editing code. Use when changes span several files or layers, migrations, or unclear scope. Execute slices with minimal-implementation. - 100scope-and-vertical-slice
Use when estimating, sizing, or adding features, when an idea feels too big, when planning a prototype or milestone, or when the user needs to decide what to cut. Keeps indie projects shippable. - 100plan-decompose
Decompose an approved plan document into self-contained task files under <plan-dir>/tasks/backlog/. Each task captures title, scope, out-of-scope, validation, tests, docs, and a final checklist — complete enough that a fresh agent can pick it up cold and ship it. Use when a plan… - 90issue-plan-slicer
Convert a spec, roadmap item, or rough plan into independently implementable issue slices with scope, dependencies, acceptance criteria, and validation. Use when the user asks to split work into GitHub issues, local markdown tasks, or agent-ready implementation chunks.