Cursor rule

1---
2description: "PLANNING SPINE STEP 1 of 3 — Scope the work: define what is in and out of scope and save as specs/product/SCOPE_LATEST.yaml. Use before slice-tasks or plan-release on any new initiative. Not a substitute for slice-tasks (step 2) or plan-work (step 3)."
3alwaysApply: false
4---
5 
6# story: e03s01
7# story: e24s02
8 
9# Scope Work
10 
11> **Spine position:** Step 1 — scope-work → slice-tasks → plan-work.
12 
13Turn the current conversation into a bounded PRD at `specs/product/SCOPE_LATEST.yaml`. Without a scope boundary, implementation drifts — stories expand, estimates blow up, and "done" becomes undefined.
14 
15## Pre-flight
16 
17- [ ] Do you have a clear user need or problem statement? If not, run `elaborate-spec` first.
18- [ ] Does `specs/product/VISION_LATEST.yaml` exist? If yes, read it for north-star alignment.
19- [ ] Is there an existing `SCOPE_LATEST.yaml`? If yes, you're refining, not creating from scratch.
20 
21## Process
22 
230. **Read planning-context.yaml** — If `specs/planning-context.yaml` exists, read it before doing anything else:
24```bash
25   test -f specs/planning-context.yaml && echo "Context found" || echo "No context — starting fresh"
26```
27   Pre-populate `feature_name`, `constraints`, and `out_of_scope` from the file. Skip re-asking questions already answered by elaborate-spec. If the file is absent, proceed normally.
28 
291. **Gather context** — Read existing `specs/` artifacts (`release-plan.yaml`, `plans/TECH_STACK_LATEST.md`, `requirements/VISION_LATEST.yaml` if any). Understand what the project is building and why.
30 
312. **Interview (if needed)** — Clarify: What is the goal? Who are the users? What is definitely in scope? What is explicitly out of scope? What constraints exist (time, budget, tech)? How will success be measured?
32 
333. **Write `specs/product/SCOPE_LATEST.yaml`** with these fields:
34   - `core_value` — one-sentence value proposition
35   - `summary` — 2-3 paragraph scope overview
36   - `in_scope[]` — list of what this initiative covers (each maps to an epic/story)
37   - `out_of_scope[]` — explicit exclusions (prevents scope creep)
38   - `constraints` — tech, time, resource boundaries
39   - `success_criteria` — observable outcomes that prove the scope is delivered
40   - `references` — links to related specs, ADRs, or documents
41 
424. **Lightweight trade-off analysis** — For each `out_of_scope` item, note *why* it's excluded (deferred, not valuable, too risky, depends on external factor). This protects against "what about X?" questions later.
43 
445. **Run `research-first`** if external dependencies are proposed — verify the dependency exists, is maintained, and fits the scope before committing to it.
45 
46> **HARD GATE** — Every `in_scope` item must map to a future epic/story ID or explicit deferred note in `out_of_scope`. If an item can't be mapped, the scope is too vague — refine before proceeding.
47 
48> **HARD GATE** — Do NOT include implementation details in SCOPE_LATEST.yaml. Scope is *what* and *why*, not *how*. Implementation detail belongs in epic capsules and slice-tasks.
49 
50## Common Anti-Patterns
51 
52- **"Everything is in scope"** — If nothing is out of scope, you haven't defined a scope. You've described a universe. Cut aggressively.
53- **"We'll figure it out later"** — Ambiguity in scope propagates to every downstream decision. Resolve now or explicitly defer in writing.
54- **Scope as architecture** — Saying "we need a PostgreSQL database" is architecture, not scope. Scope says "we need to store user profiles and transaction history."
55 
56## Output
57 
58`specs/product/SCOPE_LATEST.yaml` — the bounded PRD. Subsequent skills (`slice-tasks`, `plan-work`) reference this as the source of truth for what to build.
59 
60## Verify
61 
62→ verify: `test -f specs/product/SCOPE_LATEST.yaml && grep -q out_of_scope specs/product/SCOPE_LATEST.yaml`
63