Windsurf rules

1---
2name: scope-work
3model: sonnet
4description: "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)."
5---
6 
7# story: e03s01
8# story: e24s02
9 
10# Scope Work
11 
12> **Spine position:** Step 1 — scope-work → slice-tasks → plan-work.
13 
14Turn 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.
15 
16## Pre-flight
17 
18- [ ] Do you have a clear user need or problem statement? If not, run `elaborate-spec` first.
19- [ ] Does `specs/product/VISION_LATEST.yaml` exist? If yes, read it for north-star alignment.
20- [ ] Is there an existing `SCOPE_LATEST.yaml`? If yes, you're refining, not creating from scratch.
21 
22## Process
23 
240. **Read planning-context.yaml** — If `specs/planning-context.yaml` exists, read it before doing anything else:
25```bash
26   test -f specs/planning-context.yaml && echo "Context found" || echo "No context — starting fresh"
27```
28   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.
29 
301. **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.
31 
322. **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?
33 
343. **Write `specs/product/SCOPE_LATEST.yaml`** with these fields:
35   - `core_value` — one-sentence value proposition
36   - `summary` — 2-3 paragraph scope overview
37   - `in_scope[]` — list of what this initiative covers (each maps to an epic/story)
38   - `out_of_scope[]` — explicit exclusions (prevents scope creep)
39   - `constraints` — tech, time, resource boundaries
40   - `success_criteria` — observable outcomes that prove the scope is delivered
41   - `references` — links to related specs, ADRs, or documents
42 
434. **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.
44 
455. **Run `research-first`** if external dependencies are proposed — verify the dependency exists, is maintained, and fits the scope before committing to it.
46 
47> **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.
48 
49> **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.
50 
51## Common Anti-Patterns
52 
53- **"Everything is in scope"** — If nothing is out of scope, you haven't defined a scope. You've described a universe. Cut aggressively.
54- **"We'll figure it out later"** — Ambiguity in scope propagates to every downstream decision. Resolve now or explicitly defer in writing.
55- **Scope as architecture** — Saying "we need a PostgreSQL database" is architecture, not scope. Scope says "we need to store user profiles and transaction history."
56 
57## Output
58 
59`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.
60 
61## Verify
62 
63→ verify: `test -f specs/product/SCOPE_LATEST.yaml && grep -q out_of_scope specs/product/SCOPE_LATEST.yaml`
64