Tradebaas 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:
- Which user, in which situation, is blocked without it?
- 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.)
- 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 (
specskill). - 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 one table with your recommendation per item, in the owner's words (what it does
for whom, never a component name), and close with one question: agree with the table as it stands,
or name the rows to talk about. The owner decides, you record; a contested row gets a reply of its
own, so no reply carries more than one question.
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. ⚓