Scope

scope: the boundary is a decision, not a feeling

docs/product/BRIEF.md is the single measuring stick. This skill is the only path that changes it.

Sharpening scope

For each candidate capability, make it earn its place:

1. Which user, in which situation, is blocked without it?
2. Does an existing capability (SC-item), a platform feature, or an off-the-shelf product

already cover it? (Decision ladder: don't rebuild what exists.)

1. Can version one ship without it? If yes, it goes to Out of scope or INTAKE with a trigger.

Write results as numbered, testable SC-items. Vague scope ("a dashboard") is not scope; scope says what the user can do ("SC-3: owner sees per-project hours, filterable by month"). Phrase each one so the owner recognizes it without a translation: their words, no jargon, no component names. The progress overview quotes these lines back to them verbatim (node checks/progress.mjs), so a line only they can read is a line they cannot check.

A fuzzy word in any answer ("you said account: the Customer or the User?") gets pinned in the glossary docs/product/CONTEXT.md the moment it surfaces.

Sharpen at the project's class depth: begin §2 defines personal, team, and organization and names which BRIEF discovery rows each class answers. A change that shifts the class upward - a personal tool gains team users, a team tool reaches a client - reopens every BRIEF discovery row that says n/a: re-ask those at the new depth before widening anything else.

Triage: INTAKE.md

Nothing is built from INTAKE. Per item, propose one of:

• In scope → owner signs off → add/extend an SC-item → gets a spec (spec skill).
• Out of scope → record the reason in BRIEF's out-of-scope list. Say it plainly; a parked

good idea is not a rejection of the person.

• Later → stays in INTAKE with an explicit revisit trigger ("after launch", "if >100 users").
• Bug → not a scope question; goes straight to a fix with a regression test.

For an in-scope item, name the cheapest tier that delivers it (decision 0015: an artifact or on-demand skill before a gate, a gate before an always-on rule); the tier is part of the recommendation.

Present triage as a batch with your recommendation per item; the owner decides, you record. For a contested item or a whole-direction call, run the critical-thinking moves before recommending: a recommendation that never faced a named alternative is agreement, not triage.

Changing scope mid-build

• A scope change during a build task means: stop the task, run this skill, then resume.
• Every widening gets named as such, with its cost (time, complexity, risk) stated before the

owner decides. Silent widening is the failure mode this skill exists to prevent.

• Narrowing is allowed and healthy. Move the dropped SC-item to out-of-scope with the reason,

archive its spec as dropped.

Record

BRIEF.md updated (one fact, one place), INTAKE.md rows decided, significant scope decisions → docs/decisions/. Update STATE.md if the current work changed. ⚓

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Tradebaas
• Source: Tradebaas/Groundwork
• License: MIT
• Homepage: https://tradebaas.github.io/Groundwork/

Install and usage instructions live in the source repository linked above.