bigpowers 2.86.4 → 2.86.6

package/.cline/skills/seed-conventions/SKILL.md

@@ -0,0 +1,302 @@
+---
+name: seed-conventions
+model: sonnet
+description: "Generate CLAUDE.md and CONVENTIONS.md for a brand-new project through a brief interview, and create the specs/ directory with evolved bigpowers structure (product/, tech-architecture/, verifications/, epics/archive/). Entry point for greenfield projects. Use when starting a new project from scratch, when user asks to set up AI agent conventions, or when there is no CLAUDE.md yet."
+---
+
+# story: e10s01
+# story: e47s02
+# story: e10s02
+# story: e51s02
+# story: e45s21
+# story: e79s03
+
+
+# Seed Conventions
+> **HARD GATE** — Before any new code lands, confirm the project conventions are understood. Ask: 'What does a good commit message look like in this project?'
+
+Bootstrap a new project with the AI agent conventions it needs. Run this once at the start of a greenfield project.
+
+## What this creates
+
+- `CLAUDE.md` — Claude Code session config (project-specific)
+- `CONVENTIONS.md` — shared rules for all AI agents
+- `specs/` — the specs directory where all planning output will live
+- `AGENTS.md` — for OpenCode and other agents (optional)
+- `GEMINI.md` — for Gemini CLI (optional)
+
+## Interview
+
+Ask the user these questions (one at a time, wait for each answer):
+
+1. **Project name and one-sentence description** — "What is this project? One sentence."
+2. **Stack** — "What language, framework, and runtime? (e.g. TypeScript / Next.js / Node 22)"
+2b. **Stack profile (optional)** — Offer: `swift`, `typescript-vue`, `node-service`, or none. If chosen, merge the matching fragment from `profiles/<name>.md` into generated `CONVENTIONS.md`.
+3. **Commands** — "What commands do you use for: run, test, build, lint?"
+3b. **Preflight (optional)** — "What command runs test, lint, and build together? If none, chain Test + Lint + Build into one **Preflight** row."
+4. **Architecture** — "Key modules and relationships in 1–2 sentences."
+5. **Conventions** — "Any naming, file organization, or patterns all agents must follow?"
+6. **Never-do list** — "What are the hard stops? Things an agent must never touch?"
+7. **Defensive code categories** — "Which apply? (Rate limit / Retry / Circuit breaker / Timeout / Graceful degradation)"
+8. **Local tool wiring (optional)** — "Wire bigpowers for project-local tools? (Cursor, OpenCode, Cline, Aider, Codex CLI)" If yes, generate AGENTS.md spine artifacts per [REFERENCE.md](REFERENCE.md) §Local tool wiring and §AGENTS.md spine. If no, skip — standard seed output unchanged (no AGENTS.md spine unless opted in).
+
+## Agentic STE for generated prose (e79s03)
+
+When writing instructional lines in `CLAUDE.md`, `AGENTS.md`, or `CONVENTIONS.md`, follow [AGENTIC-STE.md](../../docs/AGENTIC-STE.md):
+
+- Use directive vocabulary: MUST, MUST NOT, NEVER, ALWAYS, DO, DO NOT
+- Do NOT use hedge modals listed in AGENTIC-STE.md Rule 3
+- Cap each instruction sentence at 20 words
+- Write imperative, active-voice lines — one instruction per line
+- Do NOT apply Agentic STE to `terse-mode` (output compression is out of scope)
+
+After generation, run `bash scripts/validate-agentic-ste.sh --strict CLAUDE.md CONVENTIONS.md` when those files exist in the target project.
+
+## Generate files
+
+After the interview, generate each file using the templates in [REFERENCE.md](REFERENCE.md):
+- `AGENTS.md` — from `docs/templates/AGENTS.md` Reach Template (canonical spine source)
+- `CLAUDE.md` — symlink to `AGENTS.md` (copy fallback on Windows when symlink fails)
+- `GEMINI.md` — symlink to `AGENTS.md` when Gemini wiring opted in
+- `opencode.json` — with `"instructions": ["AGENTS.md"]` when OpenCode opted in
+- `.aider.conf.yml` — with `read: AGENTS.md` when Aider opted in
+- `CONVENTIONS.md` — bigpowers standard template + project defensive code categories
+
+### `specs/` directory
+
+```bash
+mkdir -p specs/product specs/product/snapshots specs/epics/archive
+mkdir -p specs/tech-architecture specs/adr specs/verifications specs/bugs
+touch specs/product/SCOPE_LATEST.yaml specs/product/VISION_LATEST.yaml specs/product/GLOSSARY_LATEST.yaml
+touch specs/release-plan.yaml specs/execution-status.yaml specs/planning-status.yaml specs/state.yaml
+touch specs/tech-architecture/tech-stack.md specs/tech-architecture/SECURITY_PLAN_LATEST.md
+touch specs/tech-architecture/TEST_PLAN_LATEST.md specs/tech-architecture/DESIGN_PLAN_LATEST.md
+touch specs/tech-architecture/REFACTOR_LATEST.md specs/tech-architecture/IMPACT_LATEST.md
+touch specs/bugs/registry.yaml
+echo "# Specs\n\nAll planning documents for this project." > specs/README.md
+```
+
+**Note:** `specs/state.yaml.lock` is NOT pre-created — acquired/released dynamically.
+
+`specs/state.yaml` carries top-level `workflow_mode` (`team-pr` | `solo-git`, default `solo-git`).
+This is the **canonical integrate-mode signal** for all skills.
+Set it once here. Skills such as `release-branch` read this file instead of sniffing profiles.
+
+When generating `CLAUDE.md`, chain Test + Lint + Build into one **Preflight** row if the user named no Preflight command.
+
+### Self-installing fenced markers (e45s21)
+
+Skills that write into `CLAUDE.md` or `AGENTS.md` MUST use **fenced HTML comment markers** so handwritten content outside the fence is never clobbered:
+
+```markdown
+<!-- BEGIN bigpowers:section-id -->
+…agent-managed content only…
+<!-- END bigpowers:section-id -->
+```
+
+**Merge rule:** On update, replace only content between matching `BEGIN`/`END` pairs.
+If a marker pair is missing, append a new fenced block at file end.
+Never rewrite the whole file.
+
+**Standard marker IDs** for seeded projects (see [REFERENCE.md](REFERENCE.md) § Fenced markers):
+
+| Marker ID | Owner skill | Purpose |
+|-----------|-------------|---------|
+| `project` | seed-conventions | Project, Commands, Architecture |
+| `context-routing` | seed-conventions | Glob → sub-AGENTS.md routing table |
+| `learned-preferences` | session-state | Learned User Preferences + Workspace Facts |
+| `tooling` | setup-environment, guard-git | sqz/rtk/hook blocks installed by tooling skills |
+
+Emit these fences in `AGENTS.md` (and therefore `CLAUDE.md` symlink) from `docs/templates/AGENTS.md`. User prose outside fences is sacred.
+
+- [ ] CLAUDE.md exists and is populated
+- [ ] CONVENTIONS.md exists and includes specs/ output convention
+- [ ] specs/product/ exists with SCOPE_LATEST.yaml, VISION_LATEST.yaml, GLOSSARY_LATEST.yaml
+- [ ] specs/tech-architecture/ exists with tech-stack.md, security.md, test.md, design.md
+- [ ] specs/verifications/ exists
+- [ ] specs/epics/archive/ exists
+- [ ] specs/bugs/registry.yaml exists
+- [ ] Confirm with user: "Does CLAUDE.md accurately describe your project?"
+
+---
+
+# story: e51s02 e37s01 e37s03 e37s14
+# story: e45s21
+# Seed Conventions — Reference Templates
+
+## Navigation
+
+| Lines | Section |
+|-------|---------|
+| 1–4 | Title + story tags |
+| 6–22 | Navigation (this table) |
+| 24–35 | AGENTS.md spine |
+| 37–76 | Agent config template |
+| 78–85 | opencode.json template |
+| 87–96 | Aider bridge |
+| 98–108 | Codex CLI wiring |
+| 110–118 | CONVENTIONS.md |
+| 120–122 | Stack profile fragments |
+| 124–153 | Local tool wiring |
+
+## Fenced markers (e45s21)
+
+Self-installing blocks prevent skills from overwriting user-authored prose. Pattern:
+
+```markdown
+<!-- BEGIN bigpowers:section-id -->
+…managed content…
+<!-- END bigpowers:section-id -->
+```
+
+**Merge algorithm:**
+
+1. If `BEGIN bigpowers:<id>` exists → replace inner content only.
+2. If missing → append new fenced block at EOF.
+3. Never delete content outside fences.
+
+Seed these marker IDs in generated `AGENTS.md`:
+
+| ID | Initial content |
+|----|-----------------|
+| `project` | Project, Commands, Architecture, Conventions, Never, Agent Rules |
+| `context-routing` | Glob → sub-AGENTS.md table (see CLAUDE.md e45s22) |
+| `learned-preferences` | Empty Learned User Preferences + Workspace Facts lists |
+
+## AGENTS.md spine (Reach Template — e37s01)
+
+Canonical source: copy from `docs/templates/AGENTS.md` in the bigpowers repo (Reach Template).
+Do not invent structure ad hoc — the template includes multi-agent preamble, Preflight, Test/Lint/Build sections.
+
+When local tool wiring is opted in:
+1. Copy Reach Template → project root `AGENTS.md`, fill interview placeholders
+2. `ln -sf AGENTS.md CLAUDE.md` (or content copy on Windows when symlink fails)
+3. Write `opencode.json` with `"instructions": ["AGENTS.md"]`
+
+When user **opts out** of local tool wiring, do not emit AGENTS.md spine artifacts.
+
+## Agent config template (legacy — prefer AGENTS.md spine)
+
+All three files use the same structure — only the header differs:
+- `CLAUDE.md` → `# [Project Name] — Claude Code` (or symlink to AGENTS.md)
+- `GEMINI.md` → `# [Project Name] — Gemini CLI`
+- `AGENTS.md` → `# [Project Name] — AI Agents` (Reach Template header)
+
+```markdown
+# [Project Name] — [Agent]
+
+Read CONVENTIONS.md before any GitHub or git operation.
+
+## Project
+[One sentence description]
+Stack: [language, framework, runtime]
+
+## Commands
+| Action | Command |
+|--------|---------|
+| Run    | `[cmd]` |
+| Test   | `[cmd]` |
+| Build  | `[cmd]` |
+| Lint   | `[cmd]` |
+| Preflight | `[test && lint && build chain — or user-named full-green cmd]` |
+| CI     | `gh pr checks` (when a PR is open) |
+
+## Architecture
+[1–2 sentences. Key modules and their relationships.]
+
+## Conventions
+- [convention 1]
+- [convention 2]
+
+## Never
+- Never dismiss reproducible gate failures as pre-existing or out of scope
+- Never proceed on red Preflight or red CI — invoke quick-fix or fix-bug first
+- [hard stop 1]
+- [hard stop 2]
+
+## Agent Rules
+- **Workflow Mandate:** You MUST use the bigpowers skills (e.g. `plan-work`, `develop-tdd`, `orchestrate-project`) to perform tasks. DO NOT write code directly in response to a user prompt like "build this feature".
+- **Always Green:** Preflight and CI must be green before forward work. Reproducible gate failures require **fix-or-log** (quick-fix → fix-bug) per CONVENTIONS § Discovered Defects.
+- Read specs/ before writing code.
+- All planning and specifications MUST be written to `specs/` (`product/SCOPE_LATEST.yaml`, `release-plan.yaml`, `epics/`) before any code is generated.
+- Write the minimum code that solves the stated problem. Nothing extra.
+- Run tests after every change. Show evidence before declaring done.
+- One clarifying question beats a wrong assumption baked into 200 lines.
+```
+
+## opencode.json template
+
+```json
+{
+  "$schema": "https://opencode.ai/config.json",
+  "instructions": ["AGENTS.md"]
+}
+```
+
+## Aider — `.aider.conf.yml` bridge (e37s03)
+
+When Aider wiring is opted in:
+
+```yaml
+read: AGENTS.md
+```
+
+Upstream: [Aider-AI/aider](https://github.com/Aider-AI/aider) (not paul-gauthier/aider).
+
+## Codex CLI — project-local `.codex/config.toml` + AGENTS.md (e37s14)
+
+Source: https://developers.openai.com/codex/guides/agents-md
+
+Codex is instruction-file-only — no slash skills. When Codex wiring is opted in:
+
+```toml
+# .codex/config.toml
+instructions = ["AGENTS.md"]
+```
+
+Use AGENTS.md header `# [Project Name] — AI Agents` (shared with OpenCode/Cline). Single AGENTS.md serves dual-tool projects.
+
+## CONVENTIONS.md
+
+Use the standard bigpowers CONVENTIONS.md as the base. Fill in the project-specific defensive code categories from the interview answers.
+
+**Always embed** these doctrine sections from bigpowers (adapt commands only):
+
+- **§ Always Green / Shift Left** — 1-10-100 rationale, Preflight + CI green definitions
+- **§ Discovered Defects** — fix-or-log ladder (quick-fix → fix-bug), separate commits for discovered fixes
+- **Banned dismissive phrases** table — pre-existing, unrelated to session, not introduced by my changes, out of scope (ignoring a red gate)
+
+## Stack profile fragments
+
+If the user selected a stack profile, merge the matching `profiles/<name>.md` fragment into the generated `CONVENTIONS.md` under a `## Stack Conventions` section. Profiles supply language-specific commands, architecture patterns, and never-do additions.
+
+## Local tool wiring (optional interview step 8)
+
+Offered after the standard interview. Covers the two tools that global install (`scripts/install.sh`) structurally cannot reach because they read project-root config, not global paths.
+
+### Cursor — project-local `.cursor/rules` symlink
+
+```bash
+# From the project root:
+ln -sfn <bigpowers-install-path>/.cursor/rules .cursor/rules
+```
+
+Cursor reads `.cursor/rules/` from the project root. This symlink gives every project access to bigpowers skills as Cursor rules without duplicating the files. Run once per project.
+
+### OpenCode — project-local `opencode.json` + `AGENTS.md`
+
+`opencode.json` (project root):
+```json
+{
+  "$schema": "https://opencode.ai/config.json",
+  "instructions": [".cursor/rules/*.mdc", "AGENTS.md"]
+}
+```
+
+OpenCode reads `opencode.json` from the project root, NOT from a global path. The `instructions` array points to the local `.cursor/rules` symlink (from the Cursor step above) and the project's `AGENTS.md`. Both must exist in the project for OpenCode to see bigpowers skills.
+
+`AGENTS.md` is already generated by the standard interview (step 2 of Generate Files). When local tool wiring is opted in, ensure `AGENTS.md` includes the standard agent-config template header `# [Project Name] — OpenCode`.
+
+### When to offer
+
+Only offer local tool wiring when the user's project will be opened in Cursor or OpenCode. These tools are project-root scoped by design — no global installer can solve them. Global install (`install.sh`) already handles Claude Code, Gemini CLI, and pi globally. Do not offer for tools that read global config.

package/.cline/skills/session-state/SKILL.md

@@ -0,0 +1,146 @@
+---
+name: session-state
+model: haiku
+description: "Track implementation decisions and progress in specs/state.yaml to prevent context rot. Use at the start of a session to load context, and whenever a significant decision is made or a milestone is reached."
+---
+
+# story: e45s23
+
+# Session State
+> **HARD GATE** — **HARD GATE** — Session state must be synchronized with git state. If state.yaml conflicts with the working tree, halt and ask for clarification. Do NOT assume state is correct.
+
+
+Track the current state of implementation, including decisions made, pending tasks, and open questions, to ensure continuity across session boundaries and prevent "context rot."
+
+Session-state implements the **isolate** strategy from the context-engineering framework (docs/references/context-engineering.md): each agent gets exactly the context it needs — no more — by recording decisions so the next agent can cold-start without replaying history. The four strategies (write, select, compress, isolate) work together: session-state handles isolation, terse-mode handles compression, survey-context handles selection, and CONVENTIONS.md ensures token-efficient writing.
+
+## Goal
+
+Maintain a single source of truth for the *current* session in `specs/state.yaml`. This complements long-term docs in `specs/tech-architecture/` and delivery detail in `specs/epics/` + `specs/release-plan.yaml`.
+
+Legacy markdown (`specs/archive/STATE.md`, `RELEASE-PLAN.md`) is **not** SoT when YAML exists — use `specs/state.yaml` only.
+
+When a story modifies existing behavior, patch only between matching marker pairs in `CLAUDE.md` / `AGENTS.md` `learned-preferences` fence — see e45s21.
+
+## Handoff block (cold start)
+
+When ending a session or before a context-heavy spawn, update `handoff` in `state.yaml`:
+
+```yaml
+handoff:
+  last_step_completed: "e02s01 verify-work passed"
+  open_decisions:
+    - "Use folder mode for e07 (>5 stories)"
+  required_reading:
+    - CONVENTIONS.md
+    - specs/epics/e02-verification/epic.yaml
+  next_skill: develop-tdd
+```
+
+## Strategic compaction
+
+| Trigger | Action |
+|---------|--------|
+| Phase transition (Plan → Build → Verify) | Compact handoff; archive verbose decisions to ADR |
+| Context > 70% estimated | Run terse-mode for status only; move detail to specs/ |
+| Before `dispatch-agents` wave | `state.yaml` only channel between spawns |
+
+## Workflow
+
+### 1. Initialize (Session Start)
+
+If `specs/state.yaml` does not exist, or if starting a new major phase:
+
+- [ ] Read `specs/release-plan.yaml` and `specs/product/SCOPE_LATEST.yaml`.
+- [ ] Get git metadata: `git branch --show-current` and `git rev-parse --short HEAD`.
+- [ ] Create `specs/state.yaml` with active flow, git, handoff, and epic cycle if in build.
+
+### 2. Load (Context Refresh)
+
+When starting a new session or after a significant context flush:
+
+- [ ] Read `specs/state.yaml` to understand where the previous agent left off.
+- [ ] Read `specs/execution-status.yaml` for story progress (do not infer from release-plan).
+- [ ] Verify git matches `state.yaml` `git.branch` / `git.hash`.
+
+### 3. Update (Decision Point/Milestone)
+
+Whenever a significant decision is made or a milestone is reached:
+
+- [ ] Patch via `bash scripts/bp-yaml-set.sh specs/state.yaml git.hash <hash>` (or edit directly).
+- [ ] Patch `handoff` and `learned_preferences` / `workspace_facts` in `CLAUDE.md` fenced block when durable user preferences or repo facts crystallize (e45s23).
+- [ ] Update `handoff.open_decisions` with rationale.
+- [ ] Update `epic_cycle` when advancing `ship-epic` steps.
+- [ ] Record open questions under `handoff.open_decisions` or an ADR.
+
+→ verify: `bash scripts/validate-specs-yaml.sh`
+
+## Universal checkpoint pattern
+
+Every multi-step flow (>3 steps) in bigpowers uses a cycle counter in `state.yaml`:
+
+| Flow | Cycle key | Step field | Phases/Steps |
+|------|-----------|------------|-------------|
+| build-epic | `epic_cycle` | `current_step` | 8 (survey → release) |
+| fix-bug | `bug_cycle` | `current_step` | 5 (investigate → release) |
+| orchestrate-project | `project_cycle` | `current_phase` | 6 (discover → release) |
+
+**Checkpoint:** After each step/phase completes, increment the counter in `state.yaml` and update `handoff.next_skill`.
+
+**Resume:** On session start, read the current step/phase from the cycle key — continue from there, not from step 1.
+
+**Completed steps:** Track completed steps in `completed_steps` (comma-separated string) for audit trail.
+
+## Strategic compaction
+
+Print the current session state: `cat specs/state.yaml`, then display `active_flow` and `handoff.next_skill` for quick reference.
+
+### reset-state (absorbed)
+
+Clear ephemeral session state. Set `active_epic_id`, `active_story_id`, and `epic_cycle.current_step` to `null` in `specs/state.yaml`. Use when ending a phase or starting a new project context.
+
+### compact-state (absorbed)
+
+Archive verbose decisions before a context transition. Move all entries from `handoff.open_decisions` to their appropriate location:
+
+- **System-wide decisions** → `specs/adr/NNNN-slug.md` (global Architectural Decision Records)
+- **Epic-scoped decisions** → `specs/epics/<active_epic_id>-<slug>/adr/NNNN-slug.md` (epic-local ADRs, archived with epic)
+
+After archiving, reset `handoff.open_decisions` to an empty list.
+
+## File Format: specs/state.yaml
+
+```yaml
+active_flow: build_epic       # planning | build_epic | fix_bug
+active_epic_id: e02
+active_story_id: e02s01       # required when epic mode: folder
+active_bug_id: null           # BUG-2026-06-01T143022 when fix_bug
+release:
+  target_version: null         # NOT tracked manually — semantic-release decides at merge
+  last_tag: v2.28.0            # mirror of `gh release view`, reference only
+  last_publish: null
+epic_cycle:
+  current_step: develop-tdd
+  next_skill: develop-tdd
+  completed_steps: [kickoff-branch]
+bug_cycle:
+  current_step: null
+  completed_steps: []
+git:
+  branch: feat/e02-verify
+  hash: abc1234
+handoff:
+  last_step_completed: null
+  open_decisions: []
+  next_skill: survey-context
+```
+
+## Anti-Patterns
+
+- **Duplicate Plan**: Don't copy `release-plan.yaml` or epic shards into `state.yaml`.
+- **Stale State**: Forgetting to update `state.yaml` after a major refactor or decision.
+- **Status in release-plan**: Story/epic status lives only in `execution-status.yaml`.
+
+
+<!-- story: e03s03 -->
+<!-- story: e04s01 -->

package/.cline/skills/setup-environment/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: setup-environment
+model: haiku
+description: "Pre-install dependencies and configure tools before development work begins. Use at session start on a fresh clone, before kickoff-branch, or when user says setup environment or install deps."
+---
+
+# Setup Environment
+> **HARD GATE** — **HARD GATE** — Environment setup must be idempotent and reproducible. If setup fails, provide clear error messages and remediation steps. Do NOT assume prior state.
+
+
+Idempotent prep so BUILD phase commands succeed on first run.
+
+## Checklist
+
+1. Read `CLAUDE.md` / `CONVENTIONS.md` for required runtimes and commands.
+2. Verify runtime versions (`node -v`, `swift --version`, etc.).
+3. Install dependencies (`npm ci`, `bundle install`, etc.) — prefer lockfile installs.
+4. Copy `.env.example` → `.env` if documented; never commit secrets.
+5. Run smoke: lint + one fast test or `--version` on key tools.
+6. Record versions in `specs/state.yaml` under Environment.
+
+## BCP Plus Counter (optional)
+
+The `big-counter` tool is an optional dependency for BCP Plus 13-dimension story sizing:
+
+```bash
+# Install from PyPI (recommended)
+pip install big-counter
+
+# Or from npm
+npm install -g big-counter
+```
+
+Verify the install: `big-counter --version`
+Skip if BCP Plus sizing is not needed for this project.
+
+## Verify
+
+→ verify: `test -f CLAUDE.md && grep -q Test CLAUDE.md`

package/.cline/skills/simulate-agents/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: simulate-agents
+model: sonnet
+description: "Run Mock User and Auditor agents against a feature in fresh contexts before human review. Use after verify-work, before request-review, when user wants pre-review simulation."
+---
+
+# Simulate Agents
+> **HARD GATE** — **HARD GATE** — Simulations are hypothetical. Do NOT use sim results to make production decisions without validation on real agents. Sims help discover gaps, not replace testing.
+
+
+Two roles, **isolated contexts** (no shared state with BUILD agent):
+
+1. **Mock User** — follows Verification Script; reports UX gaps in plain language.
+2. **Auditor** — checks CONVENTIONS.md, security checklist, test coverage; structured pass/fail.
+
+## Process
+
+1. Read story Verification Script + changed files diff.
+2. Spawn Mock User: step through UAT script; log failures.
+3. Spawn Auditor: run `audit-code` checklist cold.
+4. Write `specs/SIMULATION-<feature>.md` with both reports.
+5. Failed items → `respond-review` or `plan-work` gaps — do not skip human review.
+
+## Verify
+
+→ verify: `test -f skills/simulate-agents/SKILL.md && test -d specs/verifications`

package/.cline/skills/slice-tasks/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: slice-tasks
+model: sonnet
+description: "PLANNING SPINE STEP 2 of 3 — Slice the work: break a scoped PRD into vertical-slice stories in specs/epics/. Use after scope-work (step 1), before plan-work (step 3). Not a substitute for scope-work or plan-work."
+---
+
+# story: e45s29
+
+# Slice Tasks
+
+> **Spine position:** Step 2 — scope-work → slice-tasks → plan-work.
+
+Produce **epic capsule story tasks** in `specs/epics/eNN-slug/` — vertical slices, each independently deliverable and testable. Output: decoupled `eNNsYY-tasks.yaml` files with runnable verify commands. Legacy `specs/epics/ (see slice-tasks)` is deprecated; use capsule dirs + `execution-status.yaml`.
+
+## Pre-flight
+
+- [ ] Does `specs/product/SCOPE_LATEST.yaml` exist? If not, run `scope-work` first — you can't slice what you haven't bounded.
+- [ ] Is the `release-plan.yaml` populated with the epics you're slicing? Epic IDs (e01, e02…) should exist before you create stories.
+- [ ] Do you understand the difference between a horizontal layer and a vertical slice? (See anti-patterns below.)
+
+## Process
+
+0. **Read planning-context.yaml** — If `specs/planning-context.yaml` exists, read it first:
+   ```bash
+   test -f specs/planning-context.yaml && echo "Context found" || echo "No context — starting fresh"
+   ```
+   Use `feature_name`, `constraints`, and `out_of_scope` to inform slice boundaries. `key_decisions` in the file may constrain how stories are cut (e.g., "no external deps" constrains slice 2). If absent, proceed normally.
+
+1. **Read context** — Read `specs/product/SCOPE_LATEST.yaml` and/or `specs/release-plan.yaml`. Understand what the epic delivers end-to-end.
+
+2. **Cut tracer-bullet slices** — Identify the thinnest possible vertical path through the stack that delivers user value. Start with this slice; it will catch integration issues first. For example:
+   - A search feature: first slice is "user types query → API returns results" (no filters, no pagination, no ranking — just the plumbing working end-to-end).
+   - A checkout flow: first slice is "user clicks buy → order created" (no payment, no inventory, no email).
+
+3. **Assign BCPs** — For each story, estimate Business Complexity Points (1–13). A 1-BCP story is a trivial change (one file, one concept). A 13-BCP story is a major feature across multiple modules. If a story exceeds 8 BCPs, consider splitting it.
+
+4. **Each story** writes:
+   - `eNNsYY-tasks.yaml` with `story_id`, `title`, `status`, `bcps`, `tasks[]` (each with `id`, `description`, `verify`, `status`)
+   - Story spec `.md` files are written by `plan-work` and follow countable-story-format.md
+   - The epic capsule manifest (`epic.yaml`) is updated to list the story ID and BCPs
+   - **Requirement deltas (e45s29):** Stories that alter existing behavior MUST carry `delta:` in `epic.yaml` (`ADDED` | `MODIFIED` | `REMOVED` | `RENAMED`). `plan-work` expands deltas into full before/after requirement text.
+
+5. **Order by WSJF** in `release-plan.yaml` epic list — highest WSJF first. Weight-shortest-job-first ensures the highest value arrives earliest.
+
+6. **Validate slices** — Every slice must answer: "If this story ships, does a user get new value?" If the answer is "no, they need a later story too", the slice is too horizontal — cut vertically deeper.
+
+> **HARD GATE** — No horizontal-only slices ("add all models") without a vertical path that proves integration. Every story must be independently demonstrable, even if it only handles the happy path.
+
+> **HARD GATE** — Each task's `verify:` field must contain a runnable command (not "manually check" or "review visually"). If verification requires manual steps, prefix with `verify-script:` and write the steps in the story file.
+
+## Anti-Patterns
+
+- **Layer cakes** — "Week 1: all models. Week 2: all controllers. Week 3: all views." This hides integration risk until the end. Every story must cut through all layers.
+- **Too-small slices** — If a slice takes < 30 minutes to implement, it's probably noise. Combine with adjacent slices.
+- **Too-large slices** — If a slice takes > 3 days, it's an epic, not a story. Split further.
+
+## Output
+
+- `specs/epics/eNN-slug/eNNsYY-tasks.yaml` — per-story task breakdown with verify commands
+- `specs/epics/eNN-slug/epic.yaml` — updated with story list and BCPs
+- `specs/release-plan.yaml` — updated WSJF ordering (if needed)
+
+## Verify
+
+→ verify: `[ "$(find specs/epics -name '*-tasks.yaml' 2>/dev/null | wc -l | tr -d ' ')" -gt 0 ]`
+
+
+<!-- story: e03s01 -->