Skip to content
Skills Library
Management & product · Planning

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.

Licence
MIT
Last repository change
08.11.2026

Assessment and security

100/ 100Class: good
Format25 / 25
Frontmatter with name and description, valid name, description up to 1,024 characters, name matching the folder.
Discoverability25 / 25
Description explains when to use the skill, has a reasonable length and uses third person.
Content35 / 35
At least 150 words and at most 500 lines, headings, step lists, examples or code.
Hygiene15 / 15
No placeholders such as TODO, no Windows paths, with a licence.
Riskno signals detected in the scan
Files in this package
1
Scripts
0
HTML comments
0
URLs in SKILL.md
0
Deprecation

No signals detected. Repository changed on 08.11.2026, without references to retired models or APIs.

Licence

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

  1. The document
  2. What a slice is
  3. What to produce
  4. Rules
Original SKILL.md headings · 54 lines, 417 words
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

RepositoryScoreLicence
This page · nirkaufman/claude-code-workshop-assets100MIT
crisandrews/clawcode100MIT
camoa/claude-skills100MIT
alexzio00/sovereign-skills100MIT
ccplugins/awesome-claude-code-plugins100Apache-2.0
ialameh/sift-coder100MIT
lilly-logic-labs/lll-skills90MIT
technicalpickles/pickled-claude-plugins90MIT
suboss87/FDEOps90MIT

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.

Feedback and reports

Your message goes to Bartosz Sokoliński. An email address is needed only for a reply. See the privacy policy.