# Scope

> Define, sharpen, or change project scope, and triage docs/state/INTAKE.md. Use when scope is unclear or contested, when new wishes/feedback arrive, when the owner asks for "more" mid-build, or when work doesn't trace to BRIEF.md. Scope changes only happen here, never silently during a build task.

- **Type:** Skill
- **Install:** `agentstack add skill-tradebaas-groundwork-scope`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [Tradebaas](https://agentstack.voostack.com/s/tradebaas)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [Tradebaas](https://github.com/Tradebaas)
- **Source:** https://github.com/Tradebaas/Groundwork/tree/main/.agents/skills/scope
- **Website:** https://tradebaas.github.io/Groundwork/

## Install

```sh
agentstack add skill-tradebaas-groundwork-scope
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# 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.)
3. 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](https://github.com/Tradebaas)
- **Source:** [Tradebaas/Groundwork](https://github.com/Tradebaas/Groundwork)
- **License:** MIT
- **Homepage:** https://tradebaas.github.io/Groundwork/

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

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-tradebaas-groundwork-scope
- Seller: https://agentstack.voostack.com/s/tradebaas
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.