bigpowers 1.5.1 → 2.0.1

package/dashboard/src/tui/state-yaml.js

@@ -1,17 +1,15 @@
-const chalk = require('chalk');
-
 function renderStateYaml(box, stateData) {
   if (!box || typeof box.setContent !== 'function') {
     return;
   }
 
   if (!stateData) {
-    box.setContent(chalk.dim('{center}state.yaml not found{/center}'));
+    box.setContent('{center}state.yaml not found{/center}');
     return;
   }
 
   const lines = [];
-  lines.push('{bold}{cyan}state.yaml{/cyan}{/bold}');
+  lines.push('{bold}CURRENT ACTION{/bold}');
   lines.push('');
 
   const pairs = [
@@ -27,17 +25,17 @@ function renderStateYaml(box, stateData) {
   pairs.forEach(({ key, value }) => {
     let displayValue = String(value || '—');
 
-    // Color rules
+    // Color rules: use blessed markup, not chalk
     if (key === 'git.branch') {
       if (displayValue === 'main') {
-        displayValue = chalk.green(displayValue);
+        displayValue = `{green-fg}${displayValue}{/green-fg}`;
       } else if (displayValue.startsWith('feat/')) {
-        displayValue = chalk.yellow(displayValue);
+        displayValue = `{yellow-fg}${displayValue}{/yellow-fg}`;
       }
     }
 
     if (key === 'next_skill' && value) {
-      displayValue = chalk.green(displayValue);
+      displayValue = `{green-fg}${displayValue}{/green-fg}`;
     }
 
     lines.push(`  {dim}${key}:{/dim} ${displayValue}`);

package/deepen-architecture/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: deepen-architecture
 model: sonnet
-description: Find deepening opportunities in a codebase, informed by the domain language in specs/plans/TECH_STACK_LATEST.md and the decisions in specs/adr/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable.
+description: Find deepening opportunities in a codebase, informed by the domain language in specs/tech-architecture/tech-stack.md and the decisions in specs/adr/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable.
 ---
 
 # Deepen Architecture
@@ -29,7 +29,7 @@ Key principles (see [LANGUAGE.md](LANGUAGE.md) for the full list):
 - **The interface is the test surface.**
 - **One adapter = hypothetical seam. Two adapters = real seam.**
 
-This skill is _informed_ by the project's domain model — `specs/plans/TECH_STACK_LATEST.md` and any `specs/adr/`. The domain language gives names to good seams; ADRs record decisions the skill should not re-litigate. See [CONTEXT-FORMAT.md](../model-domain/CONTEXT-FORMAT.md) and [ADR-FORMAT.md](../model-domain/ADR-FORMAT.md).
+This skill is _informed_ by the project's domain model — `specs/tech-architecture/tech-stack.md` and any `specs/adr/`. The domain language gives names to good seams; ADRs record decisions the skill should not re-litigate. See [CONTEXT-FORMAT.md](../model-domain/CONTEXT-FORMAT.md) and [ADR-FORMAT.md](../model-domain/ADR-FORMAT.md).
 
 ## Process
 
@@ -37,7 +37,7 @@ This skill is _informed_ by the project's domain model — `specs/plans/TECH_STA
 
 Read existing documentation first:
 
-- `specs/plans/TECH_STACK_LATEST.md` (or `specs/CONTEXT-MAP.md` + each `specs/plans/TECH_STACK_LATEST.md` in a multi-context repo)
+- `specs/tech-architecture/tech-stack.md` (or `specs/tech-architecture/tech-stack.md` + each `specs/tech-architecture/tech-stack.md` in a multi-context repo)
 - Relevant ADRs in `specs/adr/`
 
 If any of these files don't exist, proceed silently — don't flag their absence or suggest creating them upfront.
@@ -73,7 +73,7 @@ Present a numbered list of deepening opportunities. For each candidate:
 - **Solution** — plain English description of what would change
 - **Benefits** — explained in terms of locality and leverage, and how tests would improve
 
-**Use `specs/plans/TECH_STACK_LATEST.md` vocabulary for the domain, and [LANGUAGE.md](LANGUAGE.md) vocabulary for the architecture.**
+**Use `specs/tech-architecture/tech-stack.md` vocabulary for the domain, and [LANGUAGE.md](LANGUAGE.md) vocabulary for the architecture.**
 
 **ADR conflicts**: if a candidate contradicts an existing ADR, only surface it when the friction is real enough to warrant revisiting the ADR. Mark it clearly. Don't list every theoretical refactor an ADR forbids.
 
@@ -85,7 +85,7 @@ Once the user picks a candidate, drop into a grilling conversation. Walk the des
 
 Side effects happen inline as decisions crystallize:
 
-- **Naming a deepened module after a concept not in `specs/plans/TECH_STACK_LATEST.md`?** Add the term to `specs/plans/TECH_STACK_LATEST.md` — same discipline as `model-domain` (see [CONTEXT-FORMAT.md](../model-domain/CONTEXT-FORMAT.md)). Create the file lazily if it doesn't exist.
-- **Sharpening a fuzzy term during the conversation?** Update `specs/plans/TECH_STACK_LATEST.md` right there.
+- **Naming a deepened module after a concept not in `specs/tech-architecture/tech-stack.md`?** Add the term to `specs/tech-architecture/tech-stack.md` — same discipline as `model-domain` (see [CONTEXT-FORMAT.md](../model-domain/CONTEXT-FORMAT.md)). Create the file lazily if it doesn't exist.
+- **Sharpening a fuzzy term during the conversation?** Update `specs/tech-architecture/tech-stack.md` right there.
 - **User rejects the candidate with a load-bearing reason?** Offer an ADR, framed as: _"Want me to record this as an ADR so future architecture reviews don't re-suggest it?"_ Only offer when the reason would actually be needed by a future explorer. See [ADR-FORMAT.md](../model-domain/ADR-FORMAT.md).
 - **Want to explore alternative interfaces for the deepened module?** See [INTERFACE-DESIGN.md](INTERFACE-DESIGN.md).

package/define-success/SKILL.md

@@ -20,7 +20,7 @@ Transform "do X" into "step → verify: <cmd>" pairs. This is the pre-flight che
 
 ### 1. Read the task statement
 
-Take the task as stated (from conversation, or from `specs/epics/ (see slice-tasks)`, or from `specs/requirements/SCOPE_LATEST.yaml`).
+Take the task as stated (from conversation, or from `specs/epics/ (see slice-tasks)`, or from `specs/product/SCOPE_LATEST.yaml`).
 
 ### 2. Break into observable outcomes
 

package/develop-tdd/SKILL.md

@@ -8,7 +8,7 @@ description: Test-driven development with red-green-refactor loop using vertical
 
 > **HARD GATE** — Do NOT proceed if on `main` or `master`. Run `kickoff-branch` first to create a feature branch or worktree.
 >
-> **HARD GATE** — Do NOT write code before you have a plan. New feature: `plan-work` → epic shard tasks. Bug: `investigate-bug` → `specs/bugs/BUG-*.md` (or use `fix-bug` orchestrator).
+> **HARD GATE** — Do NOT write code before you have a plan. New feature: `plan-work` → epic capsule tasks. Bug: `investigate-bug` → `specs/bugs/BUG-*.md` (or use `fix-bug` orchestrator).
 >
 > **RECURSIVE DISCIPLINE** — This lifecycle apply to EVERY task, including updating these skills. Never skip planning because a task is "meta" or "just documentation."
 
@@ -65,7 +65,7 @@ If you find yourself thinking these things, you are likely deviating from produc
 
 Before writing any code:
 
-- [ ] Read active `specs/epics/*.yaml` story tasks or `specs/bugs/BUG-*.md` — understand verify steps
+- [ ] Read active `specs/epics/*/epic.yaml` story tasks or `specs/bugs/BUG-*.md` — understand verify steps
 - [ ] Confirm with user what interface changes are needed
 - [ ] Confirm with user which behaviors to test (prioritize)
 - [ ] Identify opportunities for [deep modules](deep-modules.md) (small interface, deep implementation)
@@ -141,7 +141,7 @@ After every behavior cycle, run the verify command from the active epic task if
 ### 6. Manual Verification Handover
 
 Once the story is complete and all tests pass:
-1. Locate the **Verification Script** in the active epic shard (`specs/epics/`) for this story.
+1. Locate the **Verification Script** in the active epic capsule (`specs/epics/`) for this story.
 2. Present the script to the user as a step-by-step guide.
 3. Wait for the user to confirm the behavioral correctness before moving to the next story or declaring the task done.
 

package/elaborate-spec/SKILL.md

@@ -63,12 +63,12 @@ Once the user has answered the main questions, probe for assumptions:
 
 ### 4. Synthesize and confirm
 
-Summarize your understanding in 3–5 bullet points:
-- The problem
-- The solution
-- The key constraints
-- The success criteria
-- What's out of scope
+Summarize your understanding in 3–5 bullet points aligned with [countable-story-format.md](file:///Users/danielvm/Developer/bigpowers/countable-story-format.md):
+- The problem (feeds into §1 Business narrative)
+- The solution and main flow (feeds into §5)
+- The key constraints and alternative flows (feeds into §6)
+- The success criteria (feeds into §17 Gherkin)
+- What's out of scope (feeds into §18)
 
 Ask: "Is this an accurate summary? Anything missing or wrong?"
 
@@ -76,7 +76,7 @@ Ask: "Is this an accurate summary? Anything missing or wrong?"
 
 Once the spec is clear, recommend the next step:
 - If domain model needs work → `model-domain`
-- If ready to plan → `plan-release` then `plan-work` per story
+- If ready to plan → `plan-release` (creates epic capsules with `epic.yaml` + story `.md` + `-tasks.yaml`) then `plan-work` per story
 - If a spike is needed first → `spike-prototype`
 - If architecture decisions are needed → `deepen-architecture` or `grill-me`
 - If the plan depends on a specific library or API → `grill-me` in docs mode

package/execute-plan/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: execute-plan
 model: haiku
-description: Batch-execute tasks from the active epic shard sequentially, with a human checkpoint after each step. Use when user has an approved plan and wants step-by-step oversight.
+description: Batch-execute tasks from the active epic capsule sequentially, with a human checkpoint after each step. Use when user has an approved plan and wants step-by-step oversight.
 ---
 
 # Execute Plan
 
-Execute tasks from the **active epic** (`specs/epics/eNN-*.yaml` story `tasks[]`) one at a time, showing evidence after each step before proceeding.
+Execute tasks from the **active epic** (`specs/epics/eNN-slug/epic.yaml` story `tasks[]`) one at a time, showing evidence after each step before proceeding.
 
 > **HARD GATE** — Do NOT proceed if on `main` or `master`. Run `kickoff-branch` first.
 >
@@ -16,7 +16,7 @@ Execute tasks from the **active epic** (`specs/epics/eNN-*.yaml` story `tasks[]`
 
 ### 1. Read the plan
 
-Read `specs/state.yaml` (`active_epic`, `active_story`) and the matching `specs/epics/*.yaml`. Parse `depends-on` in task descriptions for execution waves.
+Read `specs/state.yaml` (`active_epic`, `active_story`) and the matching `specs/epics/*/epic.yaml`. Parse `depends-on` in task descriptions for execution waves.
 
 > **CONTEXT ISOLATION** — Spawn each skill with a **fresh context window**. Pass decisions only through `specs/state.yaml` `handoff` — never rely on prior chat history.
 
@@ -44,7 +44,7 @@ Update `specs/execution-status.yaml` when a story/epic completes (`bash scripts/
 
 ### 3. Blockers
 
-Report blocker; ask skip/adapt/stop; update epic shard if plan changes.
+Report blocker; ask skip/adapt/stop; update epic capsule if plan changes.
 
 ### 4. Final report
 

package/investigate-bug/SKILL.md

@@ -69,7 +69,7 @@ Rules:
 
 ### 5. Write the bug file
 
-Save the investigation and fix plan to `specs/bugs/BUG-YYYY-MM-DDTHHMMSS.md`. Create the `specs/bugs/` directory if it doesn't exist.
+Save the investigation and fix plan to `specs/bugs/BUG-NNN-slug.md`. Create the `specs/bugs/` directory if it doesn't exist.
 
 After writing, append a row to `specs/bugs/registry.yaml` with: bug_id (same timestamp), date, severity, priority, scope, summary, and file path. Create `specs/bugs/registry.yaml` if it doesn't exist.
 

package/kickoff-branch/SKILL.md

@@ -92,7 +92,7 @@ Worktree: ../<task-slug>
 Ready to develop.
 ```
 
-Suggest next skill: `develop-tdd` to start the TDD loop, or `execute-plan` if `specs/release-plan.yaml + epic shards` already exists.
+Suggest next skill: `develop-tdd` to start the TDD loop, or `execute-plan` if `specs/release-plan.yaml + epic capsule directories` already exists.
 
 ## Handoff
 

package/map-codebase/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: map-codebase
 model: sonnet
-description: "High-fidelity codebase surveying — analyzes stack, architecture, and gray areas (error handling, API shapes) and persists them into specs/plans/TECH_STACK_LATEST.md. Goes beyond survey-context by identifying 'signals' for planning."
+description: "High-fidelity codebase surveying — analyzes stack, architecture, and gray areas (error handling, API shapes) and persists them into specs/tech-architecture/tech-stack.md. Goes beyond survey-context by identifying 'signals' for planning."
 ---
 
 # Map Codebase
@@ -38,8 +38,8 @@ Look for signals that will influence upcoming plans:
 - **Integration Points:** "We need to talk to the Stripe API, but there's no wrapper yet."
 - **Conventions:** "The team always uses functional components over classes."
 
-### 5. Persist to specs/plans/TECH_STACK_LATEST.md
-Compile all findings into `specs/plans/TECH_STACK_LATEST.md`. This file serves as the project's "Long-Term Memory".
+### 5. Persist to specs/tech-architecture/tech-stack.md
+Compile all findings into `specs/tech-architecture/tech-stack.md`. This file serves as the project's "Long-Term Memory".
 
 ```markdown
 # Project Context
@@ -66,4 +66,4 @@ Compile all findings into `specs/plans/TECH_STACK_LATEST.md`. This file serves a
 - When first joining a project.
 - Before a major refactor or architectural change.
 - When `survey-context` reveals a lack of domain knowledge.
-- To refresh `specs/plans/TECH_STACK_LATEST.md` after significant changes.
+- To refresh `specs/tech-architecture/tech-stack.md` after significant changes.

package/migrate-spec/SKILL.md

@@ -126,15 +126,15 @@ Full mapping tables: [REFERENCE-GSD.md](./REFERENCE-GSD.md) (GSD) · [REFERENCE.
 | Source | Target |
 |--------|--------|
 | GSD `ROADMAP.md` | `specs/release-plan.yaml + epic shards` |
-| GSD `REQUIREMENTS.md` | `specs/requirements/SCOPE_LATEST.yaml` |
-| GSD `CONTEXT.md` (phases) | `specs/plans/TECH_STACK_LATEST.md` + `specs/adr/` |
-| GSD `PLAN.md` | `specs/epics/eNN-*.yaml` (tasks with verify) |
-| GSD `METHODOLOGY.md` | `specs/plans/METHODOLOGY_LATEST.md` |
-| spec-kit `spec.md` | `specs/requirements/SCOPE_LATEST.yaml` + `specs/plans/TECH_STACK_LATEST.md` |
-| spec-kit `plan.md` | `specs/plans/TECH_STACK_LATEST.md` + `specs/release-plan.yaml` + `specs/epics/` |
+| GSD `REQUIREMENTS.md` | `specs/product/SCOPE_LATEST.yaml` |
+| GSD `CONTEXT.md` (phases) | `specs/tech-architecture/tech-stack.md` + `specs/adr/` |
+| GSD `PLAN.md` | `specs/epics/eNN-slug/epic.yaml` (tasks with verify in `-tasks.yaml`) |
+| GSD `METHODOLOGY.md` | `specs/tech-architecture/tech-stack.md` |
+| spec-kit `spec.md` | `specs/product/SCOPE_LATEST.yaml` + `specs/tech-architecture/tech-stack.md` |
+| spec-kit `plan.md` | `specs/tech-architecture/tech-stack.md` + `specs/release-plan.yaml` + `specs/epics/` |
 | spec-kit `tasks.md` | `specs/epics/ (see slice-tasks)` |
-| BMAD `prd.md` | `specs/requirements/SCOPE_LATEST.yaml` |
-| BMAD `architecture.md` | `specs/plans/TECH_STACK_LATEST.md` + `specs/adr/` |
+| BMAD `prd.md` | `specs/product/SCOPE_LATEST.yaml` |
+| BMAD `architecture.md` | `specs/tech-architecture/tech-stack.md` + `specs/adr/` |
 | BMAD `epic-*.md` | `specs/release-plan.yaml + epic shards` |
 | BMAD `story-*.md` | `specs/epics/ (see slice-tasks)` |
 | BMAD `project-context.md` | `CLAUDE.md` (append project-specific section) |

package/model-domain/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: model-domain
 model: sonnet
-description: Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates specs/plans/TECH_STACK_LATEST.md and specs/adr/ inline as decisions crystallise. Use when user wants to stress-test a plan against their project's domain language and documented decisions.
+description: Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates specs/tech-architecture/tech-stack.md and specs/adr/ inline as decisions crystallise. Use when user wants to stress-test a plan against their project's domain language and documented decisions.
 ---
 
 # Model Domain
@@ -32,7 +32,7 @@ Most repos have a single context:
 └── src/
 ```
 
-If a `specs/CONTEXT-MAP.md` exists, the repo has multiple contexts. The map points to where each one lives:
+If a `specs/tech-architecture/tech-stack.md` exists, the repo has multiple contexts. The map points to where each one lives:
 
 ```
 /
@@ -50,13 +50,13 @@ If a `specs/CONTEXT-MAP.md` exists, the repo has multiple contexts. The map poin
             └── adr/
 ```
 
-Create files lazily — only when you have something to write. If no `specs/plans/TECH_STACK_LATEST.md` exists, create it when the first term is resolved. If no `specs/adr/` exists, create it when the first ADR is needed.
+Create files lazily — only when you have something to write. If no `specs/tech-architecture/tech-stack.md` exists, create it when the first term is resolved. If no `specs/adr/` exists, create it when the first ADR is needed.
 
 ## During the session
 
 ### Challenge against the glossary
 
-When the user uses a term that conflicts with the existing language in `specs/plans/TECH_STACK_LATEST.md`, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?"
+When the user uses a term that conflicts with the existing language in `specs/tech-architecture/tech-stack.md`, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?"
 
 ### Sharpen fuzzy language
 
@@ -70,11 +70,11 @@ When domain relationships are being discussed, stress-test them with specific sc
 
 When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible — which is right?"
 
-### Update specs/plans/TECH_STACK_LATEST.md inline
+### Update specs/tech-architecture/tech-stack.md inline
 
-When a term is resolved, update `specs/plans/TECH_STACK_LATEST.md` right there. Don't batch these up — capture them as they happen. Use the format in [CONTEXT-FORMAT.md](./CONTEXT-FORMAT.md).
+When a term is resolved, update `specs/tech-architecture/tech-stack.md` right there. Don't batch these up — capture them as they happen. Use the format in [CONTEXT-FORMAT.md](./CONTEXT-FORMAT.md).
 
-Don't couple `specs/plans/TECH_STACK_LATEST.md` to implementation details. Only include terms that are meaningful to domain experts.
+Don't couple `specs/tech-architecture/tech-stack.md` to implementation details. Only include terms that are meaningful to domain experts.
 
 ### Offer ADRs sparingly
 
@@ -93,4 +93,4 @@ When the plan touches shared state, async, or multi-threaded code:
 - [ ] List every **shared mutable** location (globals, singletons, module-level caches).
 - [ ] For each: who reads, who writes, synchronization mechanism (lock, actor, immutable copy).
 - [ ] Flag **race risks** (check-then-act, non-atomic read-modify-write) with severity.
-- [ ] Record findings in `specs/plans/TECH_STACK_LATEST.md` under `## Concurrency` or in an ADR if architectural.
+- [ ] Record findings in `specs/tech-architecture/tech-stack.md` under `## Concurrency` or in an ADR if architectural.

package/orchestrate-project/REFERENCE.md

@@ -23,10 +23,14 @@ Detailed documentation for the `orchestrate-project` meta-skill.
 - **Gate**: Quality (request-review ≥94%) + slopcheck [SUS]/[SLOP].
 
 ### PHASE 4: BUILD
-- **Goal**: Execute the plan step-by-step using TDD and vertical slices.
-- **Deliverables**: Code; `execution-status.yaml` updated per story.
-- **Skills**: `kickoff-branch`, `develop-tdd`, `delegate-task`, `execute-plan`.
-- **Gate**: Integration tests PASS.
+- **Goal**: Execute the plan story-by-story using the 8-step `build-epic` cycle with TDD and vertical slices.
+- **Deliverables**: Code; `execution-status.yaml` updated per story; `specs/metrics/cycle-times.yaml` row per story.
+- **Skills**: `build-epic` (conductor) → per-story: `survey-context`, `plan-work`, `kickoff-branch`, `develop-tdd`, `verify-work`, `audit-code`, `commit-message`, `release-branch`.
+- **BCP tracking**: `plan-work` labels every task `[BCP N]`; total written to `state.yaml` as `epic_cycle.story_bcps`. BCP baseline must exist in `release-plan.yaml` before starting.
+- **Timestamps**: `survey-context` stamps `metrics.story_start`; `release-branch` stamps `metrics.story_end` and writes BCP/hr to `specs/metrics/cycle-times.yaml`.
+- **next_skill**: Each critical-path skill writes `handoff.next_skill` to `state.yaml`. Agents resume by reading `state.yaml` — no guessing.
+- **Dashboard**: `npm run dashboard` (TUI) or `npm run dashboard:web` (browser, port 7742) shows live pipeline, epic queue, BCP metrics, and cycle-time ledger.
+- **Gate**: Integration tests PASS; all 8 build-epic steps completed per story.
 
 ### PHASE 5: VERIFY
 - **Goal**: Validate success criteria and ensure production readiness.

package/orchestrate-project/SKILL.md

@@ -38,7 +38,7 @@ See [REFERENCE.md](REFERENCE.md) for detailed phase specifications and gate type
 
 1. **Maintains state.yaml** — Tracks current phase, `active_epic`, `active_flow`, decisions, risks.
 2. **Spawns appropriate skills** — Routes by `model:` frontmatter. Decisions pass only via `specs/state.yaml` `handoff` between spawns.
-3. **Methodology lenses** — If `specs/plans/TEST_PLAN_LATEST.md` or ADRs exist, apply at phase gates.
+3. **Methodology lenses** — If `specs/tech-architecture/test.md` or ADRs exist, apply at phase gates.
 4. **Enforces gates** — Hard stops if success criteria not met.
 5. **The Gatekeeper** — Between stories in BUILD: read `specs/execution-status.yaml`; previous story must be `done` before starting the next; use `build-epic` for the 8-step epic cycle.
 6. **Pauses for confirmation** — After each phase, asks "Ready to proceed?".
@@ -56,5 +56,5 @@ See [REFERENCE.md](REFERENCE.md) for full mode behaviors.
 
 All phases complete with artifacts:
 ```bash
-verify: test -f specs/state.yaml && test -f specs/release-plan.yaml && test -f specs/requirements/SCOPE_LATEST.yaml && ls specs/epics/*.yaml 1>/dev/null && echo "✅ All phases complete"
+verify: test -f specs/state.yaml && test -f specs/release-plan.yaml && test -f specs/product/SCOPE_LATEST.yaml && ls specs/epics/*.yaml 1>/dev/null && echo "✅ All phases complete"
 ```

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "bigpowers",
-  "version": "1.5.1",
+  "version": "2.0.1",
   "description": "61 agent skills for spec-driven, test-first software development by solo developers",
   "main": "index.js",
   "scripts": {

package/plan-release/SKILL.md

@@ -1,14 +1,14 @@
 ---
 name: plan-release
 model: sonnet
-description: Convert elaborated specs into a structured release plan with Gherkin acceptance criteria and WSJF-sorted epics. Produces specs/release-plan.yaml and specs/epics/eNN-*.yaml. Use when a spec is clear and ready to plan, after elaborate-spec, or when the user wants a release plan broken into epics and stories.
+description: Convert elaborated specs into a structured release plan with Gherkin acceptance criteria and WSJF-sorted epics. Produces specs/release-plan.yaml and epic capsule directories (specs/epics/eNN-slug/) with epic.yaml manifests, countable-story-format .md specs, and decoupled -tasks.yaml files. Use when a spec is clear and ready to plan, after elaborate-spec, or when the user wants a release plan broken into epics and stories.
 ---
 
 # Plan Release
 
 > **HARD GATE** — Do NOT run this skill unless `elaborate-spec` has produced a clear spec or the user has already defined the feature in detail. If the problem is still fuzzy, run `elaborate-spec` first.
 
-> **HARD GATE** — `specs/requirements/SCOPE_LATEST.yaml` (or legacy `specs/requirements/SCOPE_LATEST.yaml`) must exist. If missing, run `scope-work` first.
+> **HARD GATE** — `specs/product/SCOPE_LATEST.yaml` (or legacy `specs/product/SCOPE_LATEST.yaml`) must exist. If missing, run `scope-work` first.
 
 Synthesize the conversation context into `specs/release-plan.yaml` (index) and shard detail under `specs/epics/`. No new interview — only clarify if something is genuinely ambiguous.
 
@@ -16,9 +16,27 @@ Synthesize the conversation context into `specs/release-plan.yaml` (index) and s
 
 | File | Content |
 |------|---------|
-| `specs/release-plan.yaml` | `release.version`, semver bump hint, WSJF-ordered epic list (`id: e01`, `file:`, `mode:`) — **no story status** |
-| `specs/epics/eNN-<slug>.yaml` | Epic metadata, `covers: [fr-x]`, stories with tasks and `verify:` |
-| `specs/execution-status.yaml` | Regenerate keys via `bash scripts/sync-status-from-epics.sh` after epics exist |
+| `specs/release-plan.yaml` | `release.version`, semver bump hint, WSJF-ordered epic list with `id`, `capsule_dir`, `wsjf`, `bcps` — **no story status** |
+| `specs/epics/eNN-<slug>/epic.yaml` | Epic manifest: `id`, `title`, `wsjf`, `total_bcps`, `status`, `stories[]` list |
+| `specs/epics/eNN-<slug>/eNNsYY-<slug>.md` | Story spec in [countable-story-format.md](file:///Users/danielvm/Developer/bigpowers/countable-story-format.md) with 20 sections and Gherkin acceptance criteria |
+| `specs/epics/eNN-<slug>/eNNsYY-tasks.yaml` | Decoupled task checklist with `verify:` commands per task |
+| `specs/execution-status.yaml` | Flat key-value store for story status (`eNNsYY: todo`) |
+
+## Epic Capsule Structure
+
+All epics use capsule directories (no flat/folder distinction):
+
+```
+specs/epics/e01-auth-system/
+├── epic.yaml              # Epic manifest
+├── adr/                   # Epic-local ADRs (created lazily)
+├── e01s01-login.md        # Story spec (countable-story-format)
+├── e01s01-tasks.yaml      # Decoupled task checklist
+├── e01s02-jwt.md          # Story spec
+└── e01s02-tasks.yaml      # Decoupled task checklist
+```
+
+**Rationale:** Capsule dirs achieve change isolation (C9), enable archive pruning (C2/C6), and enforce SRP by decoupling spec `.md` from execution `-tasks.yaml` (C1). See `sdd-adequacy-ranking.md` for the full 10-criteria scoring.
 
 ## Process
 
@@ -49,51 +67,79 @@ release:
   bump_hint: minor          # patch | minor | major — CI decides at merge
 epics:
   - id: e01
-    title: Security
+    title: Auth System
     wsjf: 4.5
-    file: epics/e01-security.yaml
-    mode: flat              # flat | folder (folder if >5 stories)
+    capsule_dir: epics/e01-auth-system
   - id: e02
-    title: Verification
-    wsjf: 4.3
-    file: epics/e02-verification/epic.yaml
-    mode: folder
+    title: User Profile
+    wsjf: 3.8
+    capsule_dir: epics/e02-user-profile
 ```
 
-### 5. Save epic shards
+### 5. Save epic manifest (`epic.yaml`)
 
-**Flat** (`mode: flat`, ≤ ~5 stories):
+Each epic capsule directory contains an `epic.yaml` manifest:
 
 ```yaml
 id: e01
-title: Security
+title: Auth System
 wsjf: 4.5
-covers: [fr-08]
+total_bcps: 8
+status: in_progress
 stories:
   - id: e01s01
-    title: Guard git hooks
-    tasks:
-      - desc: Block push on main
-        verify: "grep -q guard-git .cursor/rules/guard-git.mdc"
+    title: Login
+    bcps: 3
+    status: todo
+    spec: e01s01-login.md
+    tasks: e01s01-tasks.yaml
+  - id: e01s02
+    title: JWT Token Management
+    bcps: 5
+    status: todo
+    spec: e01s02-jwt.md
+    tasks: e01s02-tasks.yaml
 ```
 
-**Folder GSD** (`mode: folder`): `epics/e02-verification/epic.yaml` + `stories/e02s01-*.md` with YAML frontmatter for tasks.
+### 6. Save story specs (countable-story-format .md)
 
-→ verify: `bash scripts/validate-specs-yaml.sh`
+Each story becomes a standalone `.md` file following [countable-story-format.md](file:///Users/danielvm/Developer/bigpowers/countable-story-format.md). Minimum: maturity 3 (Countable) with all 20 sections present. Acceptance criteria in §17 use Gherkin scenarios.
 
-→ verify: `grep -c 'id: e' specs/release-plan.yaml`
+### 7. Save decoupled task files (`-tasks.yaml`)
+
+Each story has a decoupled `-tasks.yaml` with implementation steps:
+
+```yaml
+story_id: e01s01
+title: Login
+status: todo
+bcps: 3
+tasks:
+  - id: 1
+    description: "Add login form component tests"
+    verify: "npm test -- login-form.test.tsx"
+    status: todo
+  - id: 2
+    description: "Implement login form with validation"
+    verify: "npm test -- login-form.test.tsx"
+    status: todo
+```
+
+> **HARD GATE** — Every task MUST have a runnable `verify:` command. No `verify:` = not a task.
+
+→ verify: `bash scripts/validate-specs-yaml.sh`
 
-### 6. Sync execution status
+### 8. Sync execution status
 
 ```bash
 bash scripts/sync-status-from-epics.sh
 ```
 
-### 7. Snapshot on planning close (optional)
+### 9. Snapshot on planning close (optional)
 
-Copy to `specs/requirements/snapshots/release-<version>/` when the user approves the plan.
+Copy to `specs/product/snapshots/release-<version>/` when the user approves the plan.
 
-### 8. Suggest next steps
+### 10. Suggest next steps
 
 - Run `assess-impact` before `plan-work` for any story touching existing modules.
 - Run `plan-work` per story for detailed steps inside the epic shard.

package/plan-work/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: plan-work
 model: opus
-description: Write detailed implementation tasks into the active epic shard (specs/epics/eNN-*.yaml). Every task must include a runnable verify command. Use when user needs step-by-step plan with evidence, or after plan-release.
+description: Write detailed implementation tasks into the active epic capsule directory (specs/epics/eNN-slug/). Produces decoupled story .md specs (countable-story-format) and runnable -tasks.yaml files. Every task must include a runnable verify command. Use when user needs step-by-step plan with evidence, or after plan-release.
 ---
 
 # Plan Work
 
-Produce a detailed, verifiable implementation plan in the **active epic shard** (`specs/epics/eNN-*.yaml` under the target story's `tasks[]`). Every step must be paired with a runnable verify command — "I think it works" is not a step.
+Produce a detailed, verifiable implementation plan in the **active epic capsule directory** (`specs/epics/eNN-slug/`). Output: a story spec `.md` file (countable-story-format) and a decoupled `eNNsYY-tasks.yaml` with runnable verify commands. "I think it works" is not a step.
 
 > **HARD GATE** — Do NOT proceed with a plan until the task's success criteria are clear. If success is ambiguous, run `define-success` first to convert the task into "step → verify: <cmd>" pairs.
 >
@@ -16,7 +16,7 @@ Produce a detailed, verifiable implementation plan in the **active epic shard**
 
 Before writing the plan, check if `define-success` has been run. If the task's success criteria are unclear, run `define-success` first to convert the task into "step → verify: <cmd>" pairs.
 
-Read any existing `specs/` files: `release-plan.yaml`, `requirements/SCOPE_LATEST.yaml`, active `epics/*.yaml`, `plans/TECH_STACK_LATEST.md`, `requirements/GLOSSARY_LATEST.yaml`.
+Read any existing `specs/` files: `release-plan.yaml`, `product/SCOPE_LATEST.yaml`, active epic capsule `epics/<capsule_dir>/epic.yaml`, `tech-architecture/tech-stack.md`, `product/GLOSSARY_LATEST.yaml`.
 
 > **ZOOM-OUT MANDATE** (v1.17.0 Guardrails) — If this plan modifies an existing module, function, or behavior:
 > 1. State the module's **purpose** — what is it responsible for?
@@ -63,11 +63,27 @@ Break the implementation into the smallest possible steps where each step:
 
 **Red-flag check**: before moving to Step 3, name any rationalization you caught yourself making — skipping a gate, adding out-of-scope steps, omitting a verify command. Write them out; do not suppress them.
 
-### 3. Write epic shard tasks
+### 3. Write capsule story spec + tasks
 
-Append tasks under the relevant story in `specs/epics/{epic-id}-*.yaml` (`tasks[]` with `desc` + `verify`). Update `specs/release-plan.yaml` if a new story is needed. Run `bash scripts/sync-status-from-epics.sh` after structural changes.
+Output two files inside the active epic capsule directory:
 
-**BCP Accounting:** Each task line MUST be prefixed `[BCP N]` where N is its sequence number. After all tasks, write `bcps: <total>` to the epic shard YAML under the story's metadata.
+**Story spec:** `specs/epics/<capsule>/eNNsYY-<slug>.md` — populated [countable-story-format](file:///Users/danielvm/Developer/bigpowers/countable-story-format.md) with all 20 sections. Minimum maturity: 3 (Countable). Acceptance criteria in §17.
+
+**Task checklist:** `specs/epics/<capsule>/eNNsYY-tasks.yaml` — decoupled execution steps:
+
+```yaml
+story_id: e01s01
+title: Login
+status: todo
+bcps: 3
+tasks:
+  - id: 1
+    description: "Add login form component tests"
+    verify: "npm test -- login-form.test.tsx"
+    status: todo
+```
+
+Update `specs/epics/<capsule>/epic.yaml` manifest to list the story and its BCPs. Run `bash scripts/sync-status-from-epics.sh` after structural changes.
 
 <plan-template>
 
@@ -133,7 +149,7 @@ Before finalizing, confirm:
 - Is the granularity right (not too coarse, not too fine)?
 - Are the verify commands actually runnable in this project?
 
-After writing epic tasks, suggest `kickoff-branch` (if not already on a feature branch) then `build-epic`, `execute-plan`, or `develop-tdd`.
+After writing capsule tasks, suggest `kickoff-branch` (if not already on a feature branch) then `build-epic`, `execute-plan`, or `develop-tdd`.
 
 ## Sub-operations
 

package/release-branch/SKILL.md

@@ -132,6 +132,21 @@ gh pr merge --squash --delete-branch
 3. Tag the repo (e.g., `v2.1.0`).
 4. Generate release notes.
 
+### 7a. Archive completed epic capsule
+
+> **HARD GATE** — When an epic's stories are all complete (all marked `done` in `execution-status.yaml`), move the epic capsule directory to the archive.
+
+```bash
+EPIC_CAPSULE="specs/epics/eNN-slug"
+if [ -d "$EPIC_CAPSULE" ]; then
+  mkdir -p specs/epics/archive
+  mv "$EPIC_CAPSULE" "specs/epics/archive/"
+  echo "Archived: $EPIC_CAPSULE → specs/epics/archive/"
+fi
+```
+
+**Rationale:** Archiving completed epics removes inactive context from the agent workspace, preserving token budget (C2/C6). The capsule directory (epic.yaml + stories + tasks + epic-local ADRs) moves as a unit — nothing is orphaned.
+
 ### 8. Clean up worktree (if not done by land-branch.sh)
 
 ```bash

package/research-first/SKILL.md

@@ -10,7 +10,7 @@ model: sonnet
 
 ## Process
 
-1. Read `specs/requirements/SCOPE_LATEST.yaml`, `specs/release-plan.yaml + epic shards`, and the current task statement.
+1. Read `specs/product/SCOPE_LATEST.yaml`, `specs/release-plan.yaml + epic shards`, and the current task statement.
 2. Search in order: this repo → bigpowers skills (`search-skills`) → package registries → web docs.
 3. For each candidate: note name, URL/path, fit (adopt | extend | compose | build).
 4. Append `## Prior Art` to `requirements/SCOPE_LATEST.yaml` notes or the active epic story.
@@ -26,6 +26,6 @@ model: sonnet
 
 ## Verify
 
-→ verify: `grep -c "Prior Art" specs/requirements/SCOPE_LATEST.yaml specs/release-plan.yaml + epic shards 2>/dev/null | awk '{s+=$1} END {if(s>0) print "OK"; else print "MISSING"}'`
+→ verify: `grep -c "Prior Art" specs/product/SCOPE_LATEST.yaml specs/release-plan.yaml + epic shards 2>/dev/null | awk '{s+=$1} END {if(s>0) print "OK"; else print "MISSING"}'`
 
 See [REFERENCE.md](REFERENCE.md) for search commands and registry checklist.