bigpowers 1.5.0 → 2.0.0

package/CHANGELOG.md

@@ -1,3 +1,38 @@
+# [2.0.0](https://github.com/danielvm-git/bigpowers/compare/v1.5.1...v2.0.0) (2026-06-11)
+
+
+* feat(skills)!: evolve to capsule-dir structure (50/50 SDD adequacy) ([77a4e88](https://github.com/danielvm-git/bigpowers/commit/77a4e88ceeb3d454079a5a499362e53c0f904379))
+
+
+### BREAKING CHANGES
+
+* Renames specs/requirements/ → specs/product/,
+specs/plans/ → specs/tech-architecture/. Epics use capsule
+directories (epic.yaml + story .md + -tasks.yaml). Adds
+specs/verifications/, state.yaml.lock, epic archive, bug registry.
+
+- 30 SKILL.md files updated across 8 change themes
+- Path renames (A+B): 10 skills for product/, 10 for tech-architecture/
+- Capsule dirs (C): 17 skills — epic.yaml manifests, countable-story
+  .md specs, decoupled -tasks.yaml
+- Verification ledger (D): verify-work + run-evals → specs/verifications/
+- State lock (E): session-state + 6 skills acquire/release state.yaml.lock
+- Bug registry (F): BUG-NNN-slug.md naming, registry.yaml
+- ADR split (G): epic-local adr/ vs global specs/adr/
+- Scripts: land-branch.sh epic archive, sync-skills.sh regeneration
+- HARD GATES: 73 callouts across 61 skills (100% coverage confirmed)
+
+Source: projected-structure-bigpowers-evolved.md (50.0/50.0 in SDD
+adequacy), sdd-adequacy-ranking.md (22-method comparison).
+Plan: specs/plans/PLAN-evolve-harmonized.md
+
+## [1.5.1](https://github.com/danielvm-git/bigpowers/compare/v1.5.0...v1.5.1) (2026-06-11)
+
+
+### Bug Fixes
+
+* **dashboard:** correct require path typo in test files ([8f7e8eb](https://github.com/danielvm-git/bigpowers/commit/8f7e8ebf02b43495c9698f4e4832b8894977d066))
+
 # [1.5.0](https://github.com/danielvm-git/bigpowers/compare/v1.4.0...v1.5.0) (2026-06-11)
 
 

package/SKILL-INDEX.md

@@ -2,7 +2,7 @@
 
 **Purpose:** One canonical reference for all bigpowers skills. Referenced by README.md, RELEASE-PLAN.md, and CONVENTIONS.md. Updated per-release.
 
-**Last updated:** 2026-06-10 (v3.1.0 — YAML cockpit; 61 active, 0 planned; 18 sub-ops absorbed into parent skills)
+**Last updated:** 2026-06-11 (v3.1.0 — verified 61 active skills; 18 sub-op concepts absorbed as sub-sections into parent SKILL.md files; count confirmed accurate)
 
 ---
 
@@ -95,7 +95,7 @@
 | 60 | Build | `run-planning` | Discover-phase workflow tracker | planning-status.yaml | ✅ Active |
 | 61 | Bug | `fix-bug` | Bug fix orchestrator | bugs/BUG-*.md | ✅ Active |
 
-**Total: 61 ✅ Active, 0 📋 Planned.**
+**Total: 61 active skills.** 18 sub-op concepts (zoom-out, slopcheck, red-phase, green-phase, refactor-phase, cold-start-smoke, gaps-loop, plan-work-fast, commit-message-fix, release-branch-hotfix, audit-code-quick, verify-work-smoke, show-state, reset-state, compact-state, list-epics, check-gates) are documented as sub-sections within parent SKILL.md files; none were standalone SKILL.md directories, so the count remains 61.
 
 ---
 

package/assess-impact/SKILL.md

@@ -27,9 +27,9 @@ git log --oneline -10 -- [file-path]
 
 ### 3. Map to release plan stories
 
-Read `specs/release-plan.yaml + epic shards` (if it exists). For each dependent found in Step 2, identify which story owns that module. List stories that will be affected by the change.
+Read `specs/release-plan.yaml + epic capsule directories` (if it exists). For each dependent found in Step 2, identify which story owns that module. List stories that will be affected by the change.
 
-→ verify: `grep -c "Story" specs/release-plan.yaml + epic shards 2>/dev/null || echo "no release plan"`
+→ verify: `grep -c "Story" specs/release-plan.yaml + epic capsule directories 2>/dev/null || echo "no release plan"`
 
 ### 4. List test coverage
 

package/build-epic/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: build-epic
 model: sonnet
-description: Eight-step epic build cycle — reads state.yaml, execution-status.yaml, and one epic shard; updates status via bp-yaml-set or direct edit. Resume mode runs one step per invocation. Use instead of ad-hoc execute-plan for release work.
+description: Eight-step epic build cycle — reads state.yaml, execution-status.yaml, and one epic capsule; updates status via bp-yaml-set or direct edit. Resume mode runs one step per invocation. Use instead of ad-hoc execute-plan for release work.
 ---
 
 # Build Epic
@@ -19,7 +19,7 @@ Orchestrates the **build** flow for a single epic: survey → plan tasks → kic
 | Step | Skill / action |
 |------|----------------|
 | 1 | `survey-context` — confirm epic + story |
-| 2 | `plan-work` — flesh out story `tasks[]` in `specs/epics/eNN-*.yaml` |
+| 2 | `plan-work` — flesh out story `tasks[]` in `specs/epics/eNN-slug/epic.yaml` |
 | 3 | `kickoff-branch` — feature branch + clean baseline |
 | 4 | `develop-tdd` — red-green per task |
 | 5 | `verify-work` — UAT + mechanical gates |
@@ -29,8 +29,8 @@ Orchestrates the **build** flow for a single epic: survey → plan tasks → kic
 
 ## Process
 
-1. Read `specs/state.yaml`, `specs/execution-status.yaml`, `specs/release-plan.yaml`, active `specs/epics/eNN-*.yaml`.
-2. **BCP Tracking (Step 2):** After `plan-work` completes, read the `bcps:` count from the epic shard and carry it into `state.yaml` as `epic_cycle.story_bcps = N`.
+1. Read `specs/state.yaml`, `specs/execution-status.yaml`, `specs/release-plan.yaml`, active `specs/epics/eNN-slug/epic.yaml`.
+2. **BCP Tracking (Step 2):** After `plan-work` completes, read the `bcps:` count from the epic capsule and carry it into `state.yaml` as `epic_cycle.story_bcps = N`.
 3. If `epic_cycle.step` missing, set to `1`.
 4. Run **only the current step** (resume mode) unless user asked for full auto-run.
 5. After step verify passes, increment `epic_cycle.step` in `state.yaml` (or `bash scripts/bp-yaml-set.sh` if available).
@@ -42,4 +42,4 @@ Write `handoff.next_skill` and `handoff.context` in `state.yaml` when pausing mi
 
 ## Verify
 
-→ verify: `grep -q 'active_flow: build_epic' specs/state.yaml && test -f specs/epics/*.yaml`
+→ verify: `grep -q 'active_flow: build_epic' specs/state.yaml && test -f specs/epics/*/epic.yaml`

package/change-request/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: change-request
 model: sonnet
-description: Add a new requirement or reorder epics by WSJF against specs/release-plan.yaml and epic shards. Modes Add and Reorder. Use when a new requirement arrives mid-release or the plan needs prioritization.
+description: Add a new requirement or reorder epics by WSJF against specs/release-plan.yaml and epic capsule directories. Modes Add and Reorder. Use when a new requirement arrives mid-release or the plan needs prioritization.
 ---
 
 # Change Request
@@ -19,10 +19,10 @@ Intake a new requirement mid-flight without disrupting work in progress.
 1. **Capture**: What is the change? What problem does it solve?
 2. **Locate**: Which existing stories in `specs/epics/` does it affect or replace?
 3. **Draft**: Add story + `tasks[]` with Gherkin-style AC in epic YAML (each task has `verify`).
-4. **Place**: Append story under existing epic shard, or create `specs/epics/eNN-slug.yaml` and register in `release-plan.yaml` `epics[]`.
+4. **Place**: Append story under existing epic capsule, or create `specs/epics/eNN-slug.yaml` and register in `release-plan.yaml` `epics[]`.
 5. **Score**: Compute WSJF; note if it outranks in-progress work.
 
-→ verify: `grep -c 'stories:' specs/epics/*.yaml`
+→ verify: `grep -c 'stories:' specs/epics/*/epic.yaml`
 
 ## Mode B — Reorder
 
@@ -36,7 +36,7 @@ See [REFERENCE.md](REFERENCE.md) for the full WSJF scoring rubric.
 4. **Update** `specs/release-plan.yaml` and epic `wsjf` keys with rationale.
 5. **Report** the delta.
 
-→ verify: `grep -c 'wsjf' specs/release-plan.yaml specs/epics/*.yaml`
+→ verify: `grep -c 'wsjf' specs/release-plan.yaml specs/epics/*/epic.yaml`
 
 ## After either mode
 

package/dashboard/src/loaders/reader.js

@@ -103,10 +103,11 @@ function readCycleTimes(projectRoot) {
     const stories = data.stories || [];
     return stories.map(s => ({
       id: s.id || null,
+      epic: s.epic || null,
       bcps: s.bcps || 0,
       start: s.start || null,
       end: s.end || null,
-      cycleMin: s.cycle_min || 0,
+      cycleMin: s.cycle_minutes || 0,
       bcpPerHour: s.bcp_per_hour || 0
     }));
   } catch (err) {

package/dashboard/src/tui/filesystem.js

@@ -1,6 +1,5 @@
 const fs = require('fs');
 const path = require('path');
-const chalk = require('chalk');
 
 function renderFilesystem(box, projectRoot) {
   if (!box || typeof box.setContent !== 'function') {
@@ -10,7 +9,7 @@ function renderFilesystem(box, projectRoot) {
   const specsPath = path.join(projectRoot, 'specs');
 
   if (!fs.existsSync(specsPath)) {
-    box.setContent(chalk.dim('{center}specs/ not found{/center}'));
+    box.setContent('{center}{dim}specs/ not found{/dim}{/center}');
     return;
   }
 
@@ -58,7 +57,7 @@ function renderFilesystem(box, projectRoot) {
           let displayName = entry.name;
 
           if (entry.isDirectory()) {
-            displayName = chalk.blue(displayName);
+            displayName = `{blue-fg}${displayName}{/blue-fg}`;
             lines.push(prefix + connector + displayName);
 
             if (depth < 1) {
@@ -73,7 +72,7 @@ function renderFilesystem(box, projectRoot) {
             const age = now - mtime;
 
             if (age < 60000) {
-              displayName = chalk.yellow(displayName + ' ★');
+              displayName = `{yellow-fg}${displayName} ★{/yellow-fg}`;
             }
 
             lines.push(prefix + connector + displayName);
@@ -86,7 +85,7 @@ function renderFilesystem(box, projectRoot) {
 
     buildTree(specsPath);
   } catch (err) {
-    lines.push(chalk.dim('Error reading specs/'));
+    lines.push('{dim}Error reading specs/{/dim}');
   }
 
   box.setContent(lines.join('\n'));

package/dashboard/src/tui/index.js

@@ -1,7 +1,7 @@
 const path = require('path');
 const { watch } = require('../loaders/watcher');
 const { readStateYaml, readExecutionStatus, readEpicShards, readCycleTimes } = require('../loaders/reader');
-const { getMetrics } = require('../loaders/metrics');
+const { computeProjectMetrics } = require('../loaders/metrics');
 const { renderPipeline } = require('./pipeline');
 const { renderEpicQueue } = require('./epic-queue');
 const { renderMetricsBar } = require('./metrics-bar');
@@ -126,7 +126,7 @@ function start(projectRoot) {
     const executionStatus = readExecutionStatus(projectRoot);
     const epics = readEpicShards(projectRoot);
     const cycleTimes = readCycleTimes(projectRoot);
-    const metrics = getMetrics(cycleTimes);
+    const metrics = computeProjectMetrics(cycleTimes);
 
     renderMetricsBar(metricsBar, metrics, stateData);
     renderPipeline(pipeline, stateData);

package/dashboard/src/tui/ledger.js

@@ -1,12 +1,10 @@
-const chalk = require('chalk');
-
 function renderLedger(box, cycleTimes) {
   if (!box || typeof box.setContent !== 'function') {
     return;
   }
 
   if (!cycleTimes || cycleTimes.length === 0) {
-    box.setContent(chalk.dim('{center}no completed stories yet{/center}'));
+    box.setContent('{center}{dim}no completed stories yet{/dim}{/center}');
     return;
   }
 
@@ -30,10 +28,10 @@ function renderLedger(box, cycleTimes) {
 
   // Data rows
   cycleTimes.forEach((cycle) => {
-    const storyId = cycle.story_id || '—';
+    const storyId = cycle.id || '—';
     const epicPrefix = cycle.epic || '—';
     const bcps = cycle.bcps || 0;
-    const minutes = cycle.cycle_minutes || 0;
+    const minutes = cycle.cycleMin || 0;
     const bcpPerHour = minutes > 0 ? ((bcps * 60) / minutes).toFixed(1) : '—';
 
     totalBCPs += bcps;

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

@@ -1,12 +1,10 @@
-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;
   }
 
@@ -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/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.0",
+  "version": "2.0.0",
   "description": "61 agent skills for spec-driven, test-first software development by solo developers",
   "main": "index.js",
   "scripts": {