bigpowers 2.73.9 → 2.74.0

package/skills/craft-skill/SKILL.md

@@ -1,3 +1,5 @@
+# story: e45s02
+<!-- story: e45s12 -->
 ---
 name: craft-skill
 model: sonnet
@@ -9,6 +11,19 @@ description: Create new bigpowers skills with proper structure, progressive disc
 
 > **HARD GATE** — Do NOT name a skill without a two-word verb-noun pair. Do NOT merge a new skill without running `sync-skills.sh` — the generated `.cursor/rules/` and `.gemini/` artifacts must match the source SKILL.md.
 
+## CSO Description Discipline (e45s02)
+
+The YAML `description` is the **Catalog Selection Object** — the only field agents see when picking a skill.
+
+| Rule | Limit |
+|------|-------|
+| Max length | 1024 characters |
+| Voice | Third person |
+| Content | Capability + `Use when …` triggers only |
+| Forbidden | Workflow steps, phase chains, numbered lists, `→ verify:`, HARD GATE prose |
+
+Move process detail into the SKILL.md body or REFERENCE.md — never into `description`.
+
 ## Process
 
 1. **Gather requirements** — ask user about:
@@ -40,6 +55,12 @@ description: Create new bigpowers skills with proper structure, progressive disc
    - Anything missing or unclear?
    - Should any section be more/less detailed?
 
+6. **Completion-honesty gate (HARD GATE — e45s02)** — Before declaring done:
+   - Run `bash scripts/validate-skill-description.sh skills/<name>/SKILL.md` — must exit 0
+   - Run `bash scripts/sync-skills.sh` — must complete without error
+   - Run `bash scripts/run-skill-verify.sh <name>` if the skill defines a verify command
+   - Show terminal output for each — narration without evidence is rejected
+
 ## Naming Rules
 
 Every skill name must be a **two-word verb-noun pair**. See [REFERENCE.md](REFERENCE.md) for full rules, examples, and documented exceptions.
@@ -53,10 +74,18 @@ If the skill produces written output, it goes in `specs/` at the project root. D
 After drafting, verify:
 
 - [ ] Name is a two-word verb-noun pair (or follows grill-me exception)
+- [ ] Description < 1024 chars, triggers only, no workflow-summary leakage
 - [ ] Description includes triggers ("Use when...")
 - [ ] SKILL.md under 100 lines
 - [ ] No time-sensitive info
 - [ ] Consistent terminology with CONVENTIONS.md
 - [ ] specs/ output documented if applicable
+- [ ] `validate-skill-description.sh` exits 0
 - [ ] `sync-skills.sh` run to propagate to Cursor/Gemini
+- [ ] `bash scripts/validate-skill-catalog.sh` passes for the new skill (HARD GATE — completion honesty)
+
+> **HARD GATE** — Do NOT declare the skill done until `bash scripts/validate-skill-catalog.sh --strict --skill <name>` exits 0. Validator enforces verb-noun name, HARD GATE block, description ≤1024 chars, and `→ verify:` command.
+
+## Verify
 
+→ verify: `bash scripts/validate-skill-catalog.sh --strict --skill craft-skill && bash scripts/validate-skill-description.sh skills/craft-skill/SKILL.md && echo OK || echo FAIL`

package/skills/deepen-architecture/SKILL.md

@@ -1,3 +1,5 @@
+# story: e45s31
+<!-- story: e45s14 -->
 ---
 name: deepen-architecture
 model: sonnet
@@ -45,6 +47,12 @@ Read existing documentation first:
 
 If any of these files don't exist, proceed silently — don't flag their absence or suggest creating them upfront.
 
+**Look-here-first (churn heuristic):** Before organic exploration, rank candidate modules by recent commit frequency. High-churn files are architectural friction magnets — start there.
+
+```bash
+bash scripts/bp-churn-rank.sh --since 90.days --limit 20
+```
+
 Then use the Agent tool with `subagent_type=Explore` to walk the codebase. Don't follow rigid heuristics — explore organically and note where you experience friction:
 
 - Where does understanding one concept require bouncing between many small modules?
@@ -93,3 +101,17 @@ Side effects happen inline as decisions crystallize:
 - **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).
 
+### 5. Import-boundary hygiene (e45s14)
+
+When a deepening move **splits or merges modules**, update `specs/import-boundaries.json` (Playwright `DEPS.list` pattern) — declare which `scripts/lib/*.sh` files may `source` which peers. CI enforces via:
+
+```bash
+bash scripts/check-import-boundaries.sh
+```
+
+Run the check before proposing cross-module `source` edges. Convention docs alone do not authorize new imports; the allowlist must list them.
+
+## Verify
+
+→ verify: `test -f specs/import-boundaries.json && bash scripts/check-import-boundaries.sh && echo OK || echo FAIL`
+

package/skills/delegate-task/SKILL.md

@@ -5,6 +5,8 @@ effort: standard
 description: Delegate one complex task to a single subagent, review its work in two stages before merging back. Sequential — one agent at a time, with oversight. Use when a task is complex and requires careful review before the result is accepted. Distinct from dispatch-agents (no parallelism here; reviewer sees full diff before proceeding).
 ---
 
+# story: e45s30
+
 # Delegate Task
 > **HARD GATE** — **HARD GATE** — Delegated work must have clear success criteria and verification commands. The delegate must be able to verify completion independently.
 
@@ -13,6 +15,18 @@ Delegate a single complex task to a subagent with a two-stage review gate before
 
 **Distinct from `dispatch-agents`:** This skill runs one subagent sequentially with a mandatory review. `dispatch-agents` runs multiple subagents in parallel without inter-task review gates.
 
+## Subagent depth tiers (e45s30)
+
+Select brief depth from task `risk:` and skill `effort:` before spawning:
+
+| Tier | When | Brief includes |
+|------|------|----------------|
+| `full_maturity` | P0 stories, multi-file refactors, security work | Full template + CONVENTIONS excerpts + threat model if present |
+| `standard` | Default implementation tasks | Goal, scope, out-of-bounds, constraints, verify, prior decisions |
+| `minimal_decisive` | Light probes, read-only audits | Goal, verify, explicit file list (≤15 lines total) |
+
+State `depth: <tier>` in the Agent tool description field.
+
 ## Process
 
 ### 1. Define the task

package/skills/deploy/SKILL.md

@@ -1,3 +1,4 @@
+<!-- story: e45s15 -->
 ---
 name: deploy
 description: "Build → verify artifact → deploy → wait → smoke deployment pipeline. Platform-agnostic (MCP or CLI), with configurable timeout, retry with exponential backoff, and integrated health-check. The deploy half of CI/CD: run after build to push to production."
@@ -105,3 +106,11 @@ For comprehensive health-checking, chain to the `smoke-test` skill:
 bash scripts/run-smoke.sh "$DEPLOY_URL"
 ```
 
+### 7. Three-independent-facts verification (e45s15)
+
+Before declaring deploy success, verify **three independent facts** — build artifact, platform accept, live/registry reachability. See [REFERENCE.md](REFERENCE.md#three-independent-facts).
+
+## Verify
+
+→ verify: `command -v curl >/dev/null 2>&1 && grep -qi 'three-independent-facts' skills/deploy/SKILL.md && echo OK || echo FAIL`
+

package/skills/develop-tdd/SKILL.md

@@ -1,4 +1,7 @@
 # story: e51s04
+# story: e45s06
+# story: e45s08
+# story: e45s34
 ---
 name: develop-tdd
 model: sonnet
@@ -52,16 +55,27 @@ Apply the **enforce-first** F.I.R.S.T rubric: Fast, Independent, Repeatable, Sel
 Write ONE test that confirms ONE thing about the system:
 
 ```
-RED:    Write test for first behavior → test fails → commit: test(<scope>): ...
-GREEN:  Write minimal code to pass → test passes → commit: feat(<scope>): ...
+RED:    Write test for first behavior → test fails → commit: test(<scope>): ...  (test-only; red in CI)
+GREEN:  Write minimal code to pass → test passes → commit: feat(<scope>): ...   (fix commit; green)
 REFACTOR (optional): clean up → commit: refactor(<scope>): ...
 ```
 
+> **Two-commit red/green policy (HARD GATE — e45s08)** — Each behavior cycle requires **two separate commits**: (1) test-only commit that fails in CI (RED), then (2) implementation commit that makes it pass (GREEN). Never combine test + fix in one commit. Show `git log -2 --oneline` as evidence before proceeding to the next behavior.
+
+> **tasks.yaml ledger (e45s06)** — After each task's `verify:` exits 0, update `eNNsYY-tasks.yaml`: set that task's `status: passing`. Story-level `status: passing` only when all tasks pass.
+
 ### 3. Incremental Loop
 
-> **STREAM CONTINUITY** — When writing file content, output in continuous chunks of ~200 lines. Do not pause. Emit a placeholder comment rather than going silent.
+> **Snapshot-before-transition (e45s34):** Before each RED → GREEN or GREEN → REFACTOR transition, create a checkpoint so a failed transition can be rolled back cleanly:
+
+```bash
+bash scripts/bp-yaml-snapshot.sh specs/state.yaml   # if state changed this cycle
+git stash push -m "tdd-checkpoint-$(git rev-parse --short HEAD)-red" --keep-index 2>/dev/null || true
+```
+
+After GREEN passes and is committed, drop the stash (`git stash drop` if empty). Never refactor while RED.
 
-For each remaining behavior: RED → GREEN → REFACTOR (optional). One test at a time. Commit after every GREEN phase.
+For each remaining behavior: RED → GREEN → REFACTOR (optional). One test at a time. **Two commits per behavior** (test-only RED, then fix GREEN). Commit after every GREEN phase.
 
 ### 4. Visual Slices (UI alternate workflow)
 

package/skills/diagnose-stall/SKILL.md

@@ -0,0 +1,56 @@
+# story: e45s38
+---
+name: diagnose-stall
+model: haiku
+effort: light
+description: Diagnose why agent orchestration stopped producing progress — silent stalls in /loop, dispatch-agents, or execute-plan. Use when work appears hung, no output for several minutes, or a subagent never returned.
+---
+
+# Diagnose Stall
+
+> **HARD GATE** — Do NOT restart work blindly. Run this diagnostic first when orchestration goes quiet without an explicit terminal state.
+
+Explicit handler for silent stalls in long-running agent workflows (`/loop`, `dispatch-agents`, `execute-plan`, `build-epic` resume mode).
+
+## Stall signals
+
+| Signal | Likely cause |
+|--------|----------------|
+| No stdout for >5 min on a monitored loop tick | Sleep/watcher misconfigured or prompt never re-armed |
+| Subagent dispatched but no completion message | Agent hung, blocked on approval, or scope too large |
+| `dispatch-agents` cycle 3 reached with gaps | Circuit exhausted — needs human escalation |
+| Verify command running >15 min | Missing timeout or waiting on external service |
+| `handoff.next_skill` unchanged across turns | Prior skill never wrote handoff |
+
+## Process
+
+1. **Read state** — `specs/state.yaml`: `handoff.next_skill`, `active_flow`, `metrics.story_start`, open decisions.
+2. **Check locks** — `bash scripts/check-stale-locks.sh` if present; read `specs/agent-locks.yaml`.
+3. **Inspect terminals** — list background shells; note PIDs, last output timestamp, exit codes.
+4. **Classify stall type:**
+   - **waiting_approval** — tool blocked on user consent
+   - **blocked_dependency** — prior task incomplete or red gate
+   - **agent_exhausted** — max iterations/cycles reached
+   - **misconfigured_loop** — duplicate sentinel, wrong regex, or sleeper not re-armed
+   - **external_io** — network, CI, or deploy wait without timeout
+   - **unknown** — escalate with evidence bundle
+5. **Recommend recovery** — one action only (resume, kill PID, re-dispatch with smaller brief, escalate to user).
+6. **Write report** — `specs/verifications/STALL-<timestamp>.md` with classification, evidence, and recommended next skill.
+
+## Integration
+
+| Caller | When to invoke |
+|--------|----------------|
+| `/loop` (Cursor) | After two consecutive ticks with no observable progress |
+| `dispatch-agents` | When a wave exceeds expected duration with zero returns |
+| `execute-plan` | When a step checkpoint is overdue |
+| User | "Why did this stop?" / "Nothing is happening" |
+
+## Verify
+
+→ verify: `test -f specs/state.yaml && echo "OK: diagnose-stall can read session state" || echo "WARN: no state.yaml — diagnostic limited"`
+
+## Handoff
+
+Gate: READY → next: survey-context (if state unclear) or resume prior skill from `state.yaml`
+Writes: `specs/verifications/STALL-*.md`

package/skills/dispatch-agents/SKILL.md

@@ -1,3 +1,5 @@
+# story: e45s38
+<!-- story: e45s11 -->
 ---
 name: dispatch-agents
 model: sonnet
@@ -5,6 +7,8 @@ effort: standard
 description: Dispatch multiple subagents in parallel on independent tasks. No waiting between them — all run concurrently. Use when tasks are truly decoupled and speed matters. Distinct from delegate-task (concurrent here, no inter-task review gate).
 ---
 
+# story: e45s30
+
 # Dispatch Agents
 > **HARD GATE** — **HARD GATE** — Agent work must be parallelizable and have explicit synchronization points. Do NOT dispatch work that has hidden dependencies between agents.
 
@@ -36,30 +40,57 @@ Before dispatching, verify each task pair is truly independent:
 
 If any two tasks conflict, sequence them with `delegate-task` or `execute-plan` instead.
 
-### 2. Write task briefs
+## Subagent depth tiers (e45s30)
 
-Before writing briefs, read `specs/state.yaml` if it exists — each agent gets only the decisions relevant to its task, nothing else.
+Map `effort:` frontmatter and story `risk:` to prompt depth — do not send `minimal_decisive` agents a `full_maturity` brief.
 
-For each task, use this minimal template (each agent starts cold — brief size directly controls token cost and hallucination risk):
+| Tier | When | Brief shape | Token budget |
+|------|------|-------------|----------------|
+| `full_maturity` | `effort: heavy`, `risk: P0`, security-sensitive diffs | Full `task_brief` + CONVENTIONS excerpts + threat model if present | Full envelope |
+| `standard` | `effort: standard`, `risk: P1`–`P2` | Standard `task_brief` fields below | Default |
+| `minimal_decisive` | `effort: light`, `risk: P3`, read-only exploration | `goal` + `verify` + `in_scope` only | ≤15 lines |
 
+Record `depth: <tier>` in the Agent tool description when dispatching.
+
+### 2. Write typed task briefs (Orca message protocol)
+
+Before writing briefs, read `specs/state.yaml` if it exists — each agent gets only the decisions relevant to its task, nothing else.
+
+Every inter-agent message uses a **typed envelope** — no freeform prose between waves:
+
+| `type` | When | Required fields |
+|--------|------|-----------------|
+| `task_brief` | Dispatch | `task_id`, `goal`, `in_scope`, `out_of_bounds`, `verify`, `prior_decisions` |
+| `checkpoint` | Mid-wave progress | `task_id`, `status` (`running`\|`blocked`), `comment` (one line) |
+| `result` | Agent return | `task_id`, `exit` (`pass`\|`fail`), `summary`, `verify_output` |
+| `circuit_open` | 3 consecutive failures | `task_id`, `failures` (3), `escalate_to` (`user`) |
+
+Example `task_brief` (each agent starts cold — brief size directly controls token cost and hallucination risk):
+
+```yaml
+type: task_brief
+task_id: agent-1
+goal: [one sentence — what success looks like]
+in_scope: [explicit file or module list]
+out_of_bounds: [what NOT to touch]
+verify: [runnable command]
+prior_decisions: [relevant entries from specs/state.yaml — omit if none]
 ```
-Goal: [one sentence — what success looks like]
-In scope: [explicit file or module list]
-Out of bounds: [what NOT to touch]
-Verify: [runnable command]
-Prior decisions: [relevant entries from specs/state.yaml — omit section if none apply]
-```
+
+Emit **`checkpoint`** comments when an agent is slow or blocked — one line, no stack traces. Parent reads checkpoints before spawning follow-ups.
 
 Do not include the full conversation, full file contents, or decisions unrelated to this agent's task.
 
-### 3. Iterative retrieval (max 3 cycles)
+### 3. Circuit breaker + iterative retrieval (max 3 cycles)
+
+Track **consecutive failures per `task_id`**. On the **3rd consecutive `result.exit: fail`** for the same task, emit `type: circuit_open` and **stop dispatching** that task — escalate to user with the three failure summaries. Reset counter on any `pass`.
 
 After each wave completes:
-1. **Dispatch** — run parallel agents with briefs.
-2. **Evaluate** — read outputs; list gaps vs goal.
+1. **Dispatch** — run parallel agents with typed `task_brief` envelopes.
+2. **Evaluate** — read `result` messages; list gaps vs goal; honor open circuits.
 3. **Refine** — tighten briefs or spawn follow-up agents (max **3 cycles** total).
 
-Stop when gaps empty or cycle 3 reached — escalate to user.
+Stop when gaps empty, circuit opens, or cycle 3 reached — escalate to user. If agents go silent without returning, invoke `diagnose-stall` before spawning another wave.
 
 ### 4. Dispatch in parallel
 
@@ -73,14 +104,15 @@ Agent 3: brief for task C
 
 ### 5. Collect and review results
 
-When all agents return:
-- Review each result independently
-- Run all verify commands
-- Check diffs for scope violations or CONVENTIONS.md breaches
+When all agents return: review each result, run verify commands, check diffs for scope violations.
 
 ### 6. Integrate
 
-Merge accepted results. If any agent's result conflicts with another, resolve manually and note the conflict.
+Merge accepted results. Resolve conflicts manually; note in summary.
+
+Report: which tasks succeeded, which need revision, overall verify status.
+
+## Verify
 
-Report a summary: which tasks succeeded, which need revision, and overall verify status.
+→ verify: `grep -q 'circuit_open' skills/dispatch-agents/SKILL.md && grep -q 'task_brief' skills/dispatch-agents/SKILL.md && echo OK || echo FAIL`
 

package/skills/gate-trace/SKILL.md

@@ -1,7 +1,9 @@
+# story: e45s05
 ---
 name: gate-trace
 description: "Deterministic traceability quality gate — reads coverage matrix + blind-spot data, applies decision rules with oracle confidence downgrade, emits PASS/CONCERNS/FAIL/WAIVED verdict. Use before release-branch to gate merges on traceability."
 # story: e38s06
+# story: e45s32
 model: haiku
 effort: light
 ---
@@ -39,7 +41,15 @@ TEA-inspired: if trace links rely on heuristics rather than explicit tags, confi
 5. Apply oracle confidence downgrade based on the heuristic link ratio from the matrix's `oracle_stats`.
 6. **Drift check (e39s03):** If `specs/drift-report.json` exists and has suspect links, mark verdict as CONCERNS with note: "Drift detected — some implementing files are newer than their specs. Run scripts/check-spec-drift.sh for details."
 7. Output verdict + rationale to stdout.
-7. Update `specs/execution-status.yaml` with gate-trace result.
+8. **Adversarial refute check (e45s32):** Before emitting PASS, attempt to **refute** the verdict — list at least one concrete traceability gap that would block merge if it were real. If the gap is real, downgrade the verdict. Rubber-stamping is prohibited; every PASS must survive one refutation attempt.
+9. **Completeness critic (e45s05)** — Run adversarial gap-finding:
+
+```bash
+bash scripts/lib/completeness-critic.sh
+```
+
+Classify output as **BLOCKER / WARNING / FILLED**. **BLOCKER overrides any PASS verdict → FAIL.** Append critic summary to rationale.
+10. Update `specs/execution-status.yaml` with gate-trace result.
 
 ## Verdict Semantics
 

package/skills/guard-git/REFERENCE.md

@@ -1,5 +1,19 @@
 # Git guardrails — reference
 
+## Navigation
+
+| Lines | Section |
+|-------|---------|
+| 1 | Title |
+| 3–14 | Navigation |
+| 16–24 | Secret patterns |
+| 26–44 | Copy layout |
+| 46–72 | Claude Code |
+| 74–92 | Cursor and Cursor CLI |
+| 94–120 | Gemini CLI |
+| 122–135 | Google Antigravity |
+| 137–178 | Verify (local tests) |
+
 ## Secret patterns (audit + pre-commit)
 
 Agents must not commit files containing:

package/skills/migrate-spec/REFERENCE.md

@@ -1,5 +1,17 @@
 # Migrate Spec — Reference
 
+## Navigation
+
+| Lines | Section |
+|-------|---------|
+| 1 | Title |
+| 3–22 | Navigation |
+| 24–62 | spec-kit → bigpowers Mapping |
+| 64–130 | BMAD → bigpowers Mapping |
+| 132–154 | Learnings to Adopt |
+| 156–350 | Output Formats + state.yaml template |
+| 352–620 | Reference blocks 1–2 + extended mappings |
+
 # migrate-spec Reference — spec-kit, BMAD, Learnings
 
 Transformation rules for spec-kit and BMAD projects, plus learnings to adopt and output formats.

package/skills/plan-work/REFERENCE.md

@@ -1,5 +1,16 @@
 # Plan Work — Reference
 
+## Navigation
+
+| Lines | Section |
+|-------|---------|
+| 1 | Title |
+| 3–14 | Navigation |
+| 16–38 | Output file formats |
+| 40–71 | Plan template |
+| 73–91 | Verify step format rules |
+| 93–131 | Sub-operations (risk, define-success, zoom-out, slopcheck, delta tags) |
+
 ## Output file formats
 
 ### Story spec: `specs/epics/<capsule>/eNNsYY-<slug>.md`
@@ -11,14 +22,14 @@ Populated countable-story-format with all 20 sections. Minimum maturity: 3 (Coun
 ```yaml
 story_id: e01s01
 title: Login
-status: todo
+status: failing
 bcps: 3
 tasks:
   - id: 1
     description: "Add login form component tests"
     verify: "npm test -- login-form.test.tsx"
     risk: P1
-    status: todo
+    status: failing   # flip to passing only after verify exits 0 (e45s06)
 ```
 
 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.
@@ -89,6 +100,22 @@ Every task and story MUST be assigned a `risk:` level (P0, P1, P2, P3). When `sp
 
 `verify-work` scales its UAT depth based on this field.
 
+### Requirement delta tags (e45s29)
+
+When modifying existing behavior in story spec § Requirements:
+
+```markdown
+#### MODIFIED: User can reset password via email link
+**Before:** Password reset required admin approval.
+**After:** Self-service reset via signed email link (expires 1h).
+
+#### REMOVED: Legacy OAuth1 login
+**Before:** OAuth1 provider supported for enterprise SSO.
+**After:** (removed) — provider deprecated; OAuth2 only.
+```
+
+Tags: `ADDED`, `MODIFIED`, `REMOVED`, `RENAMED`. `MODIFIED`/`REMOVED`/`RENAMED` without before/after → plan-work gate FAIL.
+
 ### Define Success
 
 Before planning, convert task statements into observable "step → verify: <cmd>" pairs:

package/skills/plan-work/SKILL.md

@@ -1,3 +1,8 @@
+# story: e45s04
+# story: e45s06
+# story: e45s09
+# story: e45s33
+# story: e45s35
 ---
 name: plan-work
 model: opus
@@ -5,6 +10,8 @@ effort: standard
 description: "PLANNING SPINE STEP 3 of 3 — Plan the work: write detailed implementation tasks into the active epic capsule (specs/epics/eNN-slug/). Produces countable-story-format .md specs and runnable -tasks.yaml files. Use after slice-tasks (step 2). Not a substitute for scope-work (step 1) or slice-tasks (step 2)."
 ---
 
+# story: e45s29
+
 # Plan Work
 
 > **Spine position:** Step 3 — scope-work → slice-tasks → plan-work.
@@ -46,14 +53,45 @@ If this plan touches an existing module, run `assess-impact` first to understand
 
 3. **Write capsule story spec + tasks** — Output two files inside the active epic capsule. See [REFERENCE.md](REFERENCE.md) for file formats and the plan-template. Each task MUST include a `risk:` field (`P0` | `P1` | `P2` | `P3`) based on BCP + story type heuristics (see REFERENCE.md). If a test plan artifact (`specs/tech-architecture/eNN-TEST_PLAN_LATEST.md`) exists, read it and inherit its P0/P1 risk classifications and scenario IDs (`SC-eNNsYY-P0-NN`). Each task optionally includes a `security:` field (`none` / `low` / `medium` / `high`) sourced from the epic's `specs/security/epics/<id>/THREAT_MODEL.md`. Tasks with `security: medium` or `security: high` MUST include "no new security findings in affected paths" in their verify steps.
 
+   **Requirement delta tags (e45s29):** When a story modifies existing behavior, the story spec § Requirements MUST use OpenSpec-style delta tags with mandatory before/after content:
+
+   | Tag | When | Required content |
+   |-----|------|------------------|
+   | `ADDED` | New requirement | Full requirement text |
+   | `MODIFIED` | Changed behavior | **Before:** prior behavior · **After:** new behavior |
+   | `REMOVED` | Retired requirement | **Before:** what existed · **After:** (removed) + rationale |
+   | `RENAMED` | ID or title change only | **Before:** old ID/title · **After:** new ID/title |
+
+   Net-new stories (greenfield) use `ADDED` only. `MODIFIED`/`REMOVED`/`RENAMED` without before/after blocks fail the plan-work gate.
+
 4. **Verify step format** — Every step MUST follow: `N. <What to do> → verify: <runnable command>`. See [REFERENCE.md](REFERENCE.md) for good/bad examples.
 
+4a. **Cross-artifact consistency pass (HARD GATE — e45s04)** — Before handoff, run:
+
+```bash
+bash scripts/lib/plan-consistency-check.sh specs/epics/<capsule>/
+```
+
+Print CRITICAL / HIGH / MED findings. **CRITICAL or HIGH blocks code generation** — fix capsule artifacts first. MED requires explicit user acknowledgment.
+
+4b. **tasks.yaml failing ledger (e45s06)** — Every new task entry starts with `status: failing`. Only flip to `status: passing` after its `verify:` command exits 0 during `develop-tdd` or `verify-work`. Never pre-mark passing at plan time.
+
 5. **Review with user** — Confirm step order, granularity, and that verify commands are runnable in this project.
 
+## Lifecycle Gates (e45s09)
+
+| Gate | When | Pass condition |
+|------|------|----------------|
+| **Pre-Implementation** | Before `kickoff-branch` / first RED commit | Root-cause stated for bugs; `assess-impact` done for module changes; plan-consistency-check PASS |
+| **Validation** | Story marked done | All tasks `status: passing`; verify evidence in `specs/verifications/` |
+| **Reopen-don't-refile** | Regression on shipped story | Reopen existing story/bug — do not create duplicate capsule entries |
+
 After writing capsule tasks, suggest `kickoff-branch` (if not already on a feature branch) then `build-epic`, `execute-plan`, or `develop-tdd`.
 
 ## Verify
 
+→ verify: `test -f scripts/lib/plan-consistency-check.sh && bash scripts/lib/plan-consistency-check.sh specs/epics/e45-quality-core/ 2>&1 | head -5`
+
 
 
 ## Handoff

package/skills/publish-package/REFERENCE.md

@@ -1,5 +1,16 @@
 # Publish Package — Reference
 
+## Navigation
+
+| Lines | Section |
+|-------|---------|
+| 1 | Title |
+| 3–18 | Navigation |
+| 20–28 | Options |
+| 30–60 | Examples |
+| 62–72 | Integration with release-branch |
+| 74–252 | Reference blocks 1–8 |
+
 ## Options
 
 | Flag | Description |

package/skills/release-branch/REFERENCE.md

@@ -1,5 +1,19 @@
 # Release Branch — Reference
 
+## Navigation
+
+| Lines | Section |
+|-------|---------|
+| 1–3 | Title |
+| 5–16 | Navigation |
+| 18–41 | PR body template |
+| 43–54 | Worktree cleanup |
+| 56–96 | Cycle-time recording |
+| 98–119 | CI verification |
+| 121–126 | Solo-local fallback |
+| 128–134 | Handoff |
+| 136–155 | Reference block 1 (manual squash) |
+
 # Release Branch — Reference
 
 ## PR body template (team-pr mode)