bigpowers 2.62.0 → 2.64.0

package/.pi/package.json

@@ -1,6 +1,6 @@
 {
   "name": "bigpowers",
-  "version": "2.62.0",
+  "version": "2.64.0",
   "description": "74 skills — 73 agent skills synthesizing 17 years of software engineering discipline into a prescriptive methodology for solo developers",
   "keywords": [
     "pi-package"

package/.pi/prompts/build-epic.md

@@ -33,7 +33,8 @@ Orchestrates the **build** flow for a single epic: survey → plan tasks → kic
 2. **Step 0 — Threat Model:** Run `security-review` against the epic's scope (read from the epic capsule). Output `specs/security/epics/<epic-id>/THREAT_MODEL.md` with surface area, vulnerability categories, risk level, and mitigation guidance.
 3. **Assess Impact (Step 2):** Before writing tasks, run `assess-impact --lightweight` on the proposed change. If the risk score exceeds 7, gate — require a `grill-me` session. Write the impact report to `specs/IMPACT-<epic>-<story>.md`. For net-new code with no existing dependents, skip.
 4. **BCP Tracking (Step 2):** After `plan-work` completes, read the `bcps:` count (Business Complexity Points story size) from the epic capsule and carry it into `state.yaml` as `epic_cycle.story_bcps = N`.
-5. If `epic_cycle.step` missing, set to `1`.
+5. **BCP Plus (Step 2, optional):** When the epic capsule carries a `bcp_plus_breakdown` (13-dimension sizing), also carry it into `state.yaml` as `epic_cycle.bcp_plus`. The breakdown maps each of the 13 dimensions to an integer count. NFR dimensions (11–13) that are N/A per the NFR Gate may be set to 0.
+6. If `epic_cycle.step` missing, set to `1`.
 6. Run **only the current step** (resume mode) unless user asked for full auto-run.
 7. After step verify passes, increment `epic_cycle.step` in `state.yaml` (or `bash scripts/bp-yaml-set.sh` if available).
 8. On story complete, set `execution-status.yaml` story key to `done`; run `bash scripts/sync-status-from-epics.sh`.

package/.pi/prompts/develop-tdd.md

@@ -101,6 +101,10 @@ If this cycle modified files in `.github/workflows/`, run the CI dry-run procedu
 Gate: READY -> next: verify-work
 Writes: state.yaml handoff.next_skill = verify-work
 
+## BCP Plus Integration
+
+At story completion, if the story was sized with BCP Plus (13-dimension breakdown), log the `bcp_plus.total` alongside the standard `bcps:` count in the story's tasks.yaml. The breakdown is available from the epic capsule's `bcp_plus_breakdown` field. See `docs/references/bcp-plus.md` for the full methodology and NFR Gate pattern.
+
 ---
 
 # Develop TDD — Reference

package/.pi/prompts/investigate-bug.md

@@ -117,3 +117,8 @@ A numbered list of RED-GREEN cycles:
 </diagnosis-template>
 
 After writing the bug file, print a one-line summary of the root cause and suggest running `kickoff-branch` next to create a fix branch.
+
+## References
+
+- [Feathers' Seams & Characterization Tests](../../docs/references/feathers.md) — seam types, characterization tests, and the legacy code change algorithm
+- [Fowler's Code Smells](../../docs/references/fowler.md) — identifying structural problems by smell before investigating

package/.pi/prompts/plan-refactor.md

@@ -76,4 +76,9 @@ Any further notes about the refactor.
 
 After writing `specs/REFACTOR_LATEST.md`, suggest running `kickoff-branch` next to create a refactor branch.
 
+## References
+
+- [Fowler's Refactoring Catalog](../../docs/references/fowler.md) — canonical refactoring vocabulary and code-smell taxonomy
+- [Beck's Tidy First?](../../docs/references/kent-beck.md) — structural change before behavioral change
+
 ## Verify

package/.pi/prompts/run-benchmark.md

@@ -1,5 +1,5 @@
 ---
-description: Run skill quality benchmarks from specs/benchmarks/ definitions and write pass@k reports. Use before and after evolve-skill to prove quality changes are improvements, not regressions.
+description: Run skill quality benchmarks from specs/benchmarks/ definitions — N-run with/without-skill delta grading, train/validation split, pass@k + benchmark.json reports. Use before and after evolve-skill to prove quality changes are improvements, not regressions.
 ---
 
 
@@ -7,59 +7,78 @@ description: Run skill quality benchmarks from specs/benchmarks/ definitions and
 
 > **HARD GATE** — Do NOT use benchmark scores to declare a skill "good" or "bad" in isolation. Benchmarks measure relative quality vs. a baseline — they catch regressions, they do not certify correctness.
 
-Reads benchmark definitions from `specs/benchmarks/`, executes each scenario's grader, and writes a structured `pass@k` report that `evolve-skill` consumes.
+Reads benchmark definitions from `specs/benchmarks/`, executes each scenario's grader with and without the skill loaded, and writes a structured `pass@k` report with delta grading that `evolve-skill` consumes.
 
-## Usage
+## With/Without-Skill Delta Grading
 
-```bash
-# Benchmark a single skill
-run-benchmark <skill-name>
+Every scenario runs N times (default 3) in two modes: **with** the skill loaded and **without** (bare agent with only CLAUDE.md). The delta `Δ = pass@k_with − pass@k_without` isolates the skill's causal contribution. A negative delta is a regression flag.
 
-# Benchmark all skills with definitions
-run-benchmark --all
+## Train/Validation Split
 
-# Pin current results as baseline
-run-benchmark <skill-name> --baseline
-```
+Benchmark definitions partition scenarios into two sets:
 
-## Process
+| Set | Tag | Purpose |
+|-----|-----|---------|
+| **Train** | `split: train` | Development scenarios — used while iterating. Hitting 100% on train is expected. |
+| **Validation** | `split: validation` | Held-out scenarios — the real quality signal. Overfitting train while validation stagnates is a design smell. |
+
+`pass@k` is reported separately for train and validation. Validation score is authoritative; train score is iteration guidance only.
 
-1. **Locate definition** — Read `specs/benchmarks/<skill>.yaml`. If absent, report: `"No benchmark definition found for <skill>. Create specs/benchmarks/<skill>.yaml first."` and stop.
-
-2. **Run each scenario** — For each scenario in `scenarios[]`:
-   - **Code grader:** Run `grader.command` in repo root via `bash -c`. Exit 0 → PASS. Non-zero → FAIL. Timeout: 15 seconds.
-   - **Rubric grader:** Present each criterion to the agent as a yes/no question about the scenario output. ≥ 80% yes → PASS, else FAIL.
-
-3. **Calculate pass@k** — `pass@k = sum(weight of PASS scenarios) / sum(all weights)`. Round to 2 decimal places.
-
-4. **Write report** to `specs/benchmarks/reports/BENCHMARK-<skill>-<YYYY-MM-DD>.yaml`:
-
-```yaml
-skill: survey-context
-run_date: "2026-06-22"
-pass_at_k: 0.83
-total_scenarios: 3
-passed: 2
-failed: 1
-scenarios:
-  - id: s01
-    name: "detects active epic from state.yaml"
-    result: PASS
-    weight: 1.0
-  - id: s02
-    name: "reads release-plan.yaml and reports next epic"
-    result: PASS
-    weight: 1.0
-  - id: s03
-    name: "handles missing state.yaml gracefully"
-    result: FAIL
-    weight: 0.5
-    failure_note: "crashed instead of suggesting state.yaml creation"
+## Usage
+
+```bash
+run-benchmark <skill-name>           # benchmark single skill
+run-benchmark --all                  # benchmark all with definitions
+run-benchmark <skill-name> --baseline # pin results as baseline
 ```
 
-5. **Baseline mode** (`--baseline`) — Copy the report to `specs/benchmarks/reports/BASELINE-<skill>.yaml`. This is the reference point for regression checks in `evolve-skill`.
+## Process
 
-6. **Compare to baseline** — If a `BASELINE-<skill>.yaml` exists, compare `pass_at_k`. Report:
-   - `IMPROVED: 0.67 → 0.83`
-   - `REGRESSION: 0.83 → 0.67 — do NOT ship this change`
-   - `STABLE: 0.83 = 0.83`
+1. **Locate definition** — Read `specs/benchmarks/<skill>.yaml`. If absent, stop with message.
+
+2. **Partition scenarios** — Split by `split` field (`train` → iteration, `validation` → authoritative, default: `validation`).
+
+3. **Run each scenario (N-run delta)** — For each scenario, run grader N times (default 3, configurable via `runs:`):
+   - **Without skill:** Agent with only CLAUDE.md/CONVENTIONS.md
+   - **With skill:** Agent with the skill under test active
+   - Code grader: `bash -c <command>`, exit 0 → PASS. Timeout: 15s.
+   - Rubric grader: yes/no per criterion, ≥ 80% yes → PASS.
+   - Record: `{scenario_id: {with: [P/F,...], without: [P/F,...]}}`
+
+4. **Calculate scores** — Per split (train, validation) and mode (with, without):
+   - `pass@k = sum(weight × pass_rate) / sum(weights)` where `pass_rate = passes/runs`
+   - `Δ = pass@k_with − pass@k_without` — causal contribution
+   - Round to 2 decimal places
+
+5. **Write benchmark.json** to `specs/benchmarks/reports/benchmark-<skill>.json`:
+   ```json
+   {"skill":"survey-context","run_date":"2026-06-22","runs_per_scenario":3,"train":{"with_skill":0.92,"without_skill":0.67,"delta":0.25,"scenarios":["s01","s02"]},"validation":{"with_skill":0.83,"without_skill":0.60,"delta":0.23,"scenarios":["s03","s04","s05"]}}
+   ```
+
+6. **Write YAML report** to `specs/benchmarks/reports/BENCHMARK-<skill>-<YYYY-MM-DD>.yaml`:
+   ```yaml
+   skill: survey-context
+   run_date: "2026-06-22"
+   runs_per_scenario: 3
+   train:
+     pass_at_k_with: 0.92
+     pass_at_k_without: 0.67
+     delta: 0.25
+   validation:
+     pass_at_k_with: 0.83
+     pass_at_k_without: 0.60
+     delta: 0.23
+   scenarios:
+     - id: s01
+       split: train
+       with_pass_rate: 1.0
+       without_pass_rate: 0.67
+       delta: 0.33
+       weight: 1.0
+   ```
+
+7. **Baseline** (`--baseline`) — Copy to `BASELINE-<skill>.yaml` + `baseline-<skill>.json`.
+
+8. **Compare to baseline** — `IMPROVED: Δ 0.17 → 0.25` / `REGRESSION: Δ 0.25 → 0.17 — do NOT ship` / `STABLE`.
+
+9. **Delta threshold gate** — Validation Δ < 0.0 blocks release. Δ < 0.05 warns (marginal). Min meaningful threshold: 0.05.

package/.pi/prompts/security-review.md

@@ -23,6 +23,10 @@ description: > AI-powered security analysis of code changes — traces data flow
 
 Covered: SQLi, XSS, SSRF, command injection, auth bypass, unsafe deserialization, path traversal, IDOR, crypto flaws, secrets exposure, template injection, NoSQLi
 
+## BCP Plus Integration
+
+This skill maps to **BCP Plus dimension 12 (Security & Compliance)**. When BCP Plus sizing is active, the threat model categories above correspond to sub-elements within dimension 12. The NFR Gate rule applies: standard-expectation items (e.g., "use HTTPS", "hash passwords") score 0 with a one-line rationale; only above-standard security requirements contribute to the dimension 12 count. See `docs/references/bcp-plus.md` for the full 13-dimension framework and NFR Gate pattern.
+
 ## Integration points
 
 | Skill | Touchpoint |

package/.pi/prompts/seed-conventions.md

@@ -28,6 +28,8 @@ Ask the user these questions (one at a time, wait for each answer):
 5. **Conventions** — "Any naming, file organization, or patterns all agents must follow?"
 6. **Never-do list** — "What are the hard stops? Things an agent must never touch?"
 7. **Defensive code categories** — "Which apply? (Rate limit / Retry / Circuit breaker / Timeout / Graceful degradation)"
+8. **Local tool wiring (optional)** — "Wire bigpowers skills for project-local tools that global install can't reach? (Cursor + OpenCode only)" If yes, generate the local wiring artifacts described in [REFERENCE.md](REFERENCE.md) §Local tool wiring. If no, skip — the standard seed output is unchanged.
+8. **Local tool wiring (optional)** — "Wire bigpowers skills for project-local tools that global install can't reach? (Cursor + OpenCode only)" If yes, generate the local wiring artifacts described in [REFERENCE.md](REFERENCE.md) §Local tool wiring. If no, skip — the standard seed output is unchanged.
 
 ## Generate files
 
@@ -130,3 +132,34 @@ Use the standard bigpowers CONVENTIONS.md as the base. Fill in the project-speci
 ## Stack profile fragments
 
 If the user selected a stack profile, merge the matching `profiles/<name>.md` fragment into the generated `CONVENTIONS.md` under a `## Stack Conventions` section. Profiles supply language-specific commands, architecture patterns, and never-do additions.
+
+## Local tool wiring (optional interview step 8)
+
+Offered after the standard interview. Covers the two tools that global install (`scripts/install.sh`) structurally cannot reach because they read project-root config, not global paths.
+
+### Cursor — project-local `.cursor/rules` symlink
+
+```bash
+# From the project root:
+ln -sfn <bigpowers-install-path>/.cursor/rules .cursor/rules
+```
+
+Cursor reads `.cursor/rules/` from the project root. This symlink gives every project access to bigpowers skills as Cursor rules without duplicating the files. Run once per project.
+
+### OpenCode — project-local `opencode.json` + `AGENTS.md`
+
+`opencode.json` (project root):
+```json
+{
+  "$schema": "https://opencode.ai/config.json",
+  "instructions": [".cursor/rules/*.mdc", "AGENTS.md"]
+}
+```
+
+OpenCode reads `opencode.json` from the project root, NOT from a global path. The `instructions` array points to the local `.cursor/rules` symlink (from the Cursor step above) and the project's `AGENTS.md`. Both must exist in the project for OpenCode to see bigpowers skills.
+
+`AGENTS.md` is already generated by the standard interview (step 2 of Generate Files). When local tool wiring is opted in, ensure `AGENTS.md` includes the standard agent-config template header `# [Project Name] — OpenCode`.
+
+### When to offer
+
+Only offer local tool wiring when the user's project will be opened in Cursor or OpenCode. These tools are project-root scoped by design — no global installer can solve them. Global install (`install.sh`) already handles Claude Code, Gemini CLI, and pi globally. Do not offer for tools that read global config.

package/.pi/prompts/setup-environment.md

@@ -18,6 +18,21 @@ Idempotent prep so BUILD phase commands succeed on first run.
 5. Run smoke: lint + one fast test or `--version` on key tools.
 6. Record versions in `specs/state.yaml` under Environment.
 
+## BCP Plus Counter (optional)
+
+The `big-counter` tool is an optional dependency for BCP Plus 13-dimension story sizing:
+
+```bash
+# Install from PyPI (recommended)
+pip install big-counter
+
+# Or from npm
+npm install -g big-counter
+```
+
+Verify the install: `big-counter --version`
+Skip if BCP Plus sizing is not needed for this project.
+
 ## Verify
 
 → verify: `test -f CLAUDE.md && grep -q 'Test' CLAUDE.md && echo "OK: CLAUDE.md has test table" || echo "MISSING: test commands"`

package/.pi/prompts/wire-observability.md

@@ -90,3 +90,7 @@ Place setup scripts in `scripts/setup.sh` (or language-appropriate equivalent).
 - [ ] Run `scripts/setup.sh` twice — second run should produce no errors
 - [ ] Health check command returns success
 - [ ] No sensitive data in log output
+
+## BCP Plus Integration
+
+This skill maps to **BCP Plus dimension 11 (Quality Attributes)** — specifically performance, reliability, and availability instrumentation. Structured logging, health checks, and idempotent setup scripts are observable manifestations of quality-attribute requirements. The NFR Gate rule applies: standard-expectation items (e.g., "the app should log errors") score 0 with a one-line rationale; only above-standard quality requirements (e.g., p99 latency tracking, SLO-based alerting) contribute to the dimension 11 count. See `docs/references/bcp-plus.md` for the full 13-dimension framework and NFR Gate pattern.

package/.pi/skills/build-epic/SKILL.md

@@ -35,7 +35,8 @@ Orchestrates the **build** flow for a single epic: survey → plan tasks → kic
 2. **Step 0 — Threat Model:** Run `security-review` against the epic's scope (read from the epic capsule). Output `specs/security/epics/<epic-id>/THREAT_MODEL.md` with surface area, vulnerability categories, risk level, and mitigation guidance.
 3. **Assess Impact (Step 2):** Before writing tasks, run `assess-impact --lightweight` on the proposed change. If the risk score exceeds 7, gate — require a `grill-me` session. Write the impact report to `specs/IMPACT-<epic>-<story>.md`. For net-new code with no existing dependents, skip.
 4. **BCP Tracking (Step 2):** After `plan-work` completes, read the `bcps:` count (Business Complexity Points story size) from the epic capsule and carry it into `state.yaml` as `epic_cycle.story_bcps = N`.
-5. If `epic_cycle.step` missing, set to `1`.
+5. **BCP Plus (Step 2, optional):** When the epic capsule carries a `bcp_plus_breakdown` (13-dimension sizing), also carry it into `state.yaml` as `epic_cycle.bcp_plus`. The breakdown maps each of the 13 dimensions to an integer count. NFR dimensions (11–13) that are N/A per the NFR Gate may be set to 0.
+6. If `epic_cycle.step` missing, set to `1`.
 6. Run **only the current step** (resume mode) unless user asked for full auto-run.
 7. After step verify passes, increment `epic_cycle.step` in `state.yaml` (or `bash scripts/bp-yaml-set.sh` if available).
 8. On story complete, set `execution-status.yaml` story key to `done`; run `bash scripts/sync-status-from-epics.sh`.

package/.pi/skills/develop-tdd/SKILL.md

@@ -103,6 +103,10 @@ If this cycle modified files in `.github/workflows/`, run the CI dry-run procedu
 Gate: READY -> next: verify-work
 Writes: state.yaml handoff.next_skill = verify-work
 
+## BCP Plus Integration
+
+At story completion, if the story was sized with BCP Plus (13-dimension breakdown), log the `bcp_plus.total` alongside the standard `bcps:` count in the story's tasks.yaml. The breakdown is available from the epic capsule's `bcp_plus_breakdown` field. See `docs/references/bcp-plus.md` for the full methodology and NFR Gate pattern.
+
 ---
 
 # Develop TDD — Reference

package/.pi/skills/investigate-bug/SKILL.md

@@ -119,3 +119,8 @@ A numbered list of RED-GREEN cycles:
 </diagnosis-template>
 
 After writing the bug file, print a one-line summary of the root cause and suggest running `kickoff-branch` next to create a fix branch.
+
+## References
+
+- [Feathers' Seams & Characterization Tests](../../docs/references/feathers.md) — seam types, characterization tests, and the legacy code change algorithm
+- [Fowler's Code Smells](../../docs/references/fowler.md) — identifying structural problems by smell before investigating

package/.pi/skills/plan-refactor/SKILL.md

@@ -78,4 +78,9 @@ Any further notes about the refactor.
 
 After writing `specs/REFACTOR_LATEST.md`, suggest running `kickoff-branch` next to create a refactor branch.
 
+## References
+
+- [Fowler's Refactoring Catalog](../../docs/references/fowler.md) — canonical refactoring vocabulary and code-smell taxonomy
+- [Beck's Tidy First?](../../docs/references/kent-beck.md) — structural change before behavioral change
+
 ## Verify

package/.pi/skills/run-benchmark/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: run-benchmark
-description: "Run skill quality benchmarks from specs/benchmarks/ definitions and write pass@k reports. Use before and after evolve-skill to prove quality changes are improvements, not regressions."
+description: "Run skill quality benchmarks from specs/benchmarks/ definitions — N-run with/without-skill delta grading, train/validation split, pass@k + benchmark.json reports. Use before and after evolve-skill to prove quality changes are improvements, not regressions."
 model: haiku
 ---
 
@@ -9,59 +9,78 @@ model: haiku
 
 > **HARD GATE** — Do NOT use benchmark scores to declare a skill "good" or "bad" in isolation. Benchmarks measure relative quality vs. a baseline — they catch regressions, they do not certify correctness.
 
-Reads benchmark definitions from `specs/benchmarks/`, executes each scenario's grader, and writes a structured `pass@k` report that `evolve-skill` consumes.
+Reads benchmark definitions from `specs/benchmarks/`, executes each scenario's grader with and without the skill loaded, and writes a structured `pass@k` report with delta grading that `evolve-skill` consumes.
 
-## Usage
+## With/Without-Skill Delta Grading
 
-```bash
-# Benchmark a single skill
-run-benchmark <skill-name>
+Every scenario runs N times (default 3) in two modes: **with** the skill loaded and **without** (bare agent with only CLAUDE.md). The delta `Δ = pass@k_with − pass@k_without` isolates the skill's causal contribution. A negative delta is a regression flag.
 
-# Benchmark all skills with definitions
-run-benchmark --all
+## Train/Validation Split
 
-# Pin current results as baseline
-run-benchmark <skill-name> --baseline
-```
+Benchmark definitions partition scenarios into two sets:
 
-## Process
+| Set | Tag | Purpose |
+|-----|-----|---------|
+| **Train** | `split: train` | Development scenarios — used while iterating. Hitting 100% on train is expected. |
+| **Validation** | `split: validation` | Held-out scenarios — the real quality signal. Overfitting train while validation stagnates is a design smell. |
+
+`pass@k` is reported separately for train and validation. Validation score is authoritative; train score is iteration guidance only.
 
-1. **Locate definition** — Read `specs/benchmarks/<skill>.yaml`. If absent, report: `"No benchmark definition found for <skill>. Create specs/benchmarks/<skill>.yaml first."` and stop.
-
-2. **Run each scenario** — For each scenario in `scenarios[]`:
-   - **Code grader:** Run `grader.command` in repo root via `bash -c`. Exit 0 → PASS. Non-zero → FAIL. Timeout: 15 seconds.
-   - **Rubric grader:** Present each criterion to the agent as a yes/no question about the scenario output. ≥ 80% yes → PASS, else FAIL.
-
-3. **Calculate pass@k** — `pass@k = sum(weight of PASS scenarios) / sum(all weights)`. Round to 2 decimal places.
-
-4. **Write report** to `specs/benchmarks/reports/BENCHMARK-<skill>-<YYYY-MM-DD>.yaml`:
-
-```yaml
-skill: survey-context
-run_date: "2026-06-22"
-pass_at_k: 0.83
-total_scenarios: 3
-passed: 2
-failed: 1
-scenarios:
-  - id: s01
-    name: "detects active epic from state.yaml"
-    result: PASS
-    weight: 1.0
-  - id: s02
-    name: "reads release-plan.yaml and reports next epic"
-    result: PASS
-    weight: 1.0
-  - id: s03
-    name: "handles missing state.yaml gracefully"
-    result: FAIL
-    weight: 0.5
-    failure_note: "crashed instead of suggesting state.yaml creation"
+## Usage
+
+```bash
+run-benchmark <skill-name>           # benchmark single skill
+run-benchmark --all                  # benchmark all with definitions
+run-benchmark <skill-name> --baseline # pin results as baseline
 ```
 
-5. **Baseline mode** (`--baseline`) — Copy the report to `specs/benchmarks/reports/BASELINE-<skill>.yaml`. This is the reference point for regression checks in `evolve-skill`.
+## Process
 
-6. **Compare to baseline** — If a `BASELINE-<skill>.yaml` exists, compare `pass_at_k`. Report:
-   - `IMPROVED: 0.67 → 0.83`
-   - `REGRESSION: 0.83 → 0.67 — do NOT ship this change`
-   - `STABLE: 0.83 = 0.83`
+1. **Locate definition** — Read `specs/benchmarks/<skill>.yaml`. If absent, stop with message.
+
+2. **Partition scenarios** — Split by `split` field (`train` → iteration, `validation` → authoritative, default: `validation`).
+
+3. **Run each scenario (N-run delta)** — For each scenario, run grader N times (default 3, configurable via `runs:`):
+   - **Without skill:** Agent with only CLAUDE.md/CONVENTIONS.md
+   - **With skill:** Agent with the skill under test active
+   - Code grader: `bash -c <command>`, exit 0 → PASS. Timeout: 15s.
+   - Rubric grader: yes/no per criterion, ≥ 80% yes → PASS.
+   - Record: `{scenario_id: {with: [P/F,...], without: [P/F,...]}}`
+
+4. **Calculate scores** — Per split (train, validation) and mode (with, without):
+   - `pass@k = sum(weight × pass_rate) / sum(weights)` where `pass_rate = passes/runs`
+   - `Δ = pass@k_with − pass@k_without` — causal contribution
+   - Round to 2 decimal places
+
+5. **Write benchmark.json** to `specs/benchmarks/reports/benchmark-<skill>.json`:
+   ```json
+   {"skill":"survey-context","run_date":"2026-06-22","runs_per_scenario":3,"train":{"with_skill":0.92,"without_skill":0.67,"delta":0.25,"scenarios":["s01","s02"]},"validation":{"with_skill":0.83,"without_skill":0.60,"delta":0.23,"scenarios":["s03","s04","s05"]}}
+   ```
+
+6. **Write YAML report** to `specs/benchmarks/reports/BENCHMARK-<skill>-<YYYY-MM-DD>.yaml`:
+   ```yaml
+   skill: survey-context
+   run_date: "2026-06-22"
+   runs_per_scenario: 3
+   train:
+     pass_at_k_with: 0.92
+     pass_at_k_without: 0.67
+     delta: 0.25
+   validation:
+     pass_at_k_with: 0.83
+     pass_at_k_without: 0.60
+     delta: 0.23
+   scenarios:
+     - id: s01
+       split: train
+       with_pass_rate: 1.0
+       without_pass_rate: 0.67
+       delta: 0.33
+       weight: 1.0
+   ```
+
+7. **Baseline** (`--baseline`) — Copy to `BASELINE-<skill>.yaml` + `baseline-<skill>.json`.
+
+8. **Compare to baseline** — `IMPROVED: Δ 0.17 → 0.25` / `REGRESSION: Δ 0.25 → 0.17 — do NOT ship` / `STABLE`.
+
+9. **Delta threshold gate** — Validation Δ < 0.0 blocks release. Δ < 0.05 warns (marginal). Min meaningful threshold: 0.05.

package/.pi/skills/security-review/SKILL.md

@@ -25,6 +25,10 @@ model: sonnet
 
 Covered: SQLi, XSS, SSRF, command injection, auth bypass, unsafe deserialization, path traversal, IDOR, crypto flaws, secrets exposure, template injection, NoSQLi
 
+## BCP Plus Integration
+
+This skill maps to **BCP Plus dimension 12 (Security & Compliance)**. When BCP Plus sizing is active, the threat model categories above correspond to sub-elements within dimension 12. The NFR Gate rule applies: standard-expectation items (e.g., "use HTTPS", "hash passwords") score 0 with a one-line rationale; only above-standard security requirements contribute to the dimension 12 count. See `docs/references/bcp-plus.md` for the full 13-dimension framework and NFR Gate pattern.
+
 ## Integration points
 
 | Skill | Touchpoint |

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

@@ -30,6 +30,8 @@ Ask the user these questions (one at a time, wait for each answer):
 5. **Conventions** — "Any naming, file organization, or patterns all agents must follow?"
 6. **Never-do list** — "What are the hard stops? Things an agent must never touch?"
 7. **Defensive code categories** — "Which apply? (Rate limit / Retry / Circuit breaker / Timeout / Graceful degradation)"
+8. **Local tool wiring (optional)** — "Wire bigpowers skills for project-local tools that global install can't reach? (Cursor + OpenCode only)" If yes, generate the local wiring artifacts described in [REFERENCE.md](REFERENCE.md) §Local tool wiring. If no, skip — the standard seed output is unchanged.
+8. **Local tool wiring (optional)** — "Wire bigpowers skills for project-local tools that global install can't reach? (Cursor + OpenCode only)" If yes, generate the local wiring artifacts described in [REFERENCE.md](REFERENCE.md) §Local tool wiring. If no, skip — the standard seed output is unchanged.
 
 ## Generate files
 
@@ -132,3 +134,34 @@ Use the standard bigpowers CONVENTIONS.md as the base. Fill in the project-speci
 ## Stack profile fragments
 
 If the user selected a stack profile, merge the matching `profiles/<name>.md` fragment into the generated `CONVENTIONS.md` under a `## Stack Conventions` section. Profiles supply language-specific commands, architecture patterns, and never-do additions.
+
+## Local tool wiring (optional interview step 8)
+
+Offered after the standard interview. Covers the two tools that global install (`scripts/install.sh`) structurally cannot reach because they read project-root config, not global paths.
+
+### Cursor — project-local `.cursor/rules` symlink
+
+```bash
+# From the project root:
+ln -sfn <bigpowers-install-path>/.cursor/rules .cursor/rules
+```
+
+Cursor reads `.cursor/rules/` from the project root. This symlink gives every project access to bigpowers skills as Cursor rules without duplicating the files. Run once per project.
+
+### OpenCode — project-local `opencode.json` + `AGENTS.md`
+
+`opencode.json` (project root):
+```json
+{
+  "$schema": "https://opencode.ai/config.json",
+  "instructions": [".cursor/rules/*.mdc", "AGENTS.md"]
+}
+```
+
+OpenCode reads `opencode.json` from the project root, NOT from a global path. The `instructions` array points to the local `.cursor/rules` symlink (from the Cursor step above) and the project's `AGENTS.md`. Both must exist in the project for OpenCode to see bigpowers skills.
+
+`AGENTS.md` is already generated by the standard interview (step 2 of Generate Files). When local tool wiring is opted in, ensure `AGENTS.md` includes the standard agent-config template header `# [Project Name] — OpenCode`.
+
+### When to offer
+
+Only offer local tool wiring when the user's project will be opened in Cursor or OpenCode. These tools are project-root scoped by design — no global installer can solve them. Global install (`install.sh`) already handles Claude Code, Gemini CLI, and pi globally. Do not offer for tools that read global config.

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

@@ -20,6 +20,21 @@ Idempotent prep so BUILD phase commands succeed on first run.
 5. Run smoke: lint + one fast test or `--version` on key tools.
 6. Record versions in `specs/state.yaml` under Environment.
 
+## BCP Plus Counter (optional)
+
+The `big-counter` tool is an optional dependency for BCP Plus 13-dimension story sizing:
+
+```bash
+# Install from PyPI (recommended)
+pip install big-counter
+
+# Or from npm
+npm install -g big-counter
+```
+
+Verify the install: `big-counter --version`
+Skip if BCP Plus sizing is not needed for this project.
+
 ## Verify
 
 → verify: `test -f CLAUDE.md && grep -q 'Test' CLAUDE.md && echo "OK: CLAUDE.md has test table" || echo "MISSING: test commands"`

package/.pi/skills/wire-observability/SKILL.md

@@ -92,3 +92,7 @@ Place setup scripts in `scripts/setup.sh` (or language-appropriate equivalent).
 - [ ] Run `scripts/setup.sh` twice — second run should produce no errors
 - [ ] Health check command returns success
 - [ ] No sensitive data in log output
+
+## BCP Plus Integration
+
+This skill maps to **BCP Plus dimension 11 (Quality Attributes)** — specifically performance, reliability, and availability instrumentation. Structured logging, health checks, and idempotent setup scripts are observable manifestations of quality-attribute requirements. The NFR Gate rule applies: standard-expectation items (e.g., "the app should log errors") score 0 with a one-line rationale; only above-standard quality requirements (e.g., p99 latency tracking, SLO-based alerting) contribute to the dimension 11 count. See `docs/references/bcp-plus.md` for the full 13-dimension framework and NFR Gate pattern.

package/CHANGELOG.md

@@ -1,3 +1,27 @@
+# [2.64.0](https://github.com/danielvm-git/bigpowers/compare/v2.63.0...v2.64.0) (2026-07-05)
+
+
+### Features
+
+* **e33:** Docs Website — fourth generated artifact target ([ff7f3ec](https://github.com/danielvm-git/bigpowers/commit/ff7f3ec6eab7c4b30a9676888468af5c9c9dd196))
+* **e35:** missing historical references — 10 stories, 8 new ref docs ([ffba59f](https://github.com/danielvm-git/bigpowers/commit/ffba59f3ebbe18a72385a3f325a5856a8a53da9e))
+* **e37s01:** BCP Plus counter integration — setup-environment + bcp-plus reference ([f2b4bdf](https://github.com/danielvm-git/bigpowers/commit/f2b4bdf86b6256089b593207aec37480e789edb7))
+* **e37s03:** NFR Gate integration — security-review and wire-observability sizing ([de47871](https://github.com/danielvm-git/bigpowers/commit/de478716f22e1b576a4b936103144aac39e921a4))
+* **e37s04:** Build-epic integration — BCP Plus in story sizing workflow ([a961e6b](https://github.com/danielvm-git/bigpowers/commit/a961e6be3c7f6a984654b38c4a867423ac6c11db))
+* **e43:** showcase repo — full worked example + sync-skills regeneration ([a872ca8](https://github.com/danielvm-git/bigpowers/commit/a872ca82745c6e7b983ef45f42f3251d3df0d680))
+* **e43:** showcase repo — full worked example of bigpowers methodology ([e32373b](https://github.com/danielvm-git/bigpowers/commit/e32373bff09cd0bf01a06406a95fccff8ad54f47)), closes [#dependent](https://github.com/danielvm-git/bigpowers/issues/dependent)
+* **e47:** cross-tool skill distribution — pi install, seed wiring, docs, verify harness ([0109c2f](https://github.com/danielvm-git/bigpowers/commit/0109c2fd87e2c2ef783e335a7e3d10e268ba5162))
+* **e48s01:** benchmark schema v2 — split/runs fields, story tags ([47bc1ef](https://github.com/danielvm-git/bigpowers/commit/47bc1ef92e6c34b01dc199f22b6edf357f5f0120))
+* **e48s01:** run-benchmark — delta grading + train/validation split ([d2d1fe8](https://github.com/danielvm-git/bigpowers/commit/d2d1fe84ec923f34454b7bdac40205667f18760f))
+* **e48s01:** run-benchmark — with/without-skill delta grading + train/validation split ([651d0d8](https://github.com/danielvm-git/bigpowers/commit/651d0d8b2c44477fa3be08162a5e0ecde2db2258))
+
+# [2.63.0](https://github.com/danielvm-git/bigpowers/compare/v2.62.0...v2.63.0) (2026-07-05)
+
+
+### Features
+
+* **e47:** cross-tool skill distribution — pi install, seed wiring, docs, verify harness ([27c68b4](https://github.com/danielvm-git/bigpowers/commit/27c68b49b698e994b783abc85c3750637061664e))
+
 # [2.62.0](https://github.com/danielvm-git/bigpowers/compare/v2.61.4...v2.62.0) (2026-07-05)
 
 

package/CLAUDE.md

@@ -35,6 +35,8 @@ npm run compliance && bash scripts/run-golden-suite.sh
 
 If any gate fails, fix before merging. Run `--baseline` after any intentional increase in skill count or structure.
 
+**BCP Plus:** For stories sized with the 13-dimension BCP Plus methodology, confirm the `bcp_plus_breakdown` is present in the epic YAML and carried into `state.yaml` as `epic_cycle.bcp_plus`. See `docs/references/bcp-plus.md` for the NFR Gate pattern.
+
 ## Architecture
 
 Collection of verb-noun skills under `skills/`, each with a SKILL.md source file and supporting documentation. Runtime specs live in `specs/state.yaml`, `specs/release-plan.yaml`, and `specs/execution-status.yaml`; intent in `specs/product/`; epic shards in `specs/epics/`. The sync-skills.sh script auto-generates artifacts for Cursor (.cursor/rules) and Gemini CLI (.gemini/extensions/bigpowers/) from SKILL.md sources. All planning output goes to specs/ at the project root.
@@ -46,10 +48,12 @@ Collection of verb-noun skills under `skills/`, each with a SKILL.md source file
 - All planning/spec output goes to specs/ at project root
 - Artifacts in .cursor/rules and .gemini/ are auto-generated; edit SKILL.md, not artifacts
 - Run sync-skills.sh after any SKILL.md changes to regenerate artifacts
+- Website content in website/src/content/docs/ is auto-generated by prebuild; edit repo sources, not site files
 
 ## Never
 
 - Never edit .cursor/rules or .gemini/extensions/ directly — these are generated files
+- Never edit website/src/content/docs/ directly — these are generated files; website/ is the fourth generated artifact target (alongside .cursor/, .gemini/, .pi/)
 - Never create a skill without a SKILL.md file and proper verb-noun naming
 - Never push changes without running sync-skills.sh first
 

package/CONVENTIONS.md

@@ -140,6 +140,16 @@ When planning closes, copy to `specs/product/snapshots/release-<version>/` (`rel
 
 Validate YAML layout: `bash scripts/validate-specs-yaml.sh`. Patch runtime keys: `bash scripts/bp-yaml-set.sh specs/state.yaml git.branch feat/foo`.
 
+### Generated artifact targets
+
+Skill content is edited in `skills/*/SKILL.md` and auto-propagated to these targets by `bash scripts/sync-skills.sh`:
+- `.cursor/rules/` — Cursor IDE rules
+- `.gemini/extensions/bigpowers/` — Gemini CLI extensions
+- `.pi/skills/` + `.pi/prompts/` — pi agent
+- `website/src/content/docs/` — Docs website (Astro Starlight, deployed to GitHub Pages)
+
+**Never edit any of these targets directly.** Edit the SKILL.md sources and run rebuild scripts (`bash scripts/sync-skills.sh`, `npm run site:build`).
+
 ### Legacy paths (migrate away)
 
 | Old | New |

package/README.md

@@ -12,6 +12,12 @@ It is not a random collection of best practices. It is a chronological layer cak
 
 Published on npm: [bigpowers](https://www.npmjs.com/package/bigpowers). The skill count in the badge above is stamped automatically by `sync-skills.sh`; the canonical catalog is [`SKILL-INDEX.md`](SKILL-INDEX.md).
 
+Docs: [bigpowers docs site](https://danielvm-git.github.io/bigpowers/) — searchable, Google-discoverable reference for all skills, guides, and ADRs.
+
+**This methodology publishes its own evidence — see the [live receipts page](https://danielvm-git.github.io/bigpowers/receipts/).**
+
+**See it working:** [bigpowers-showcase](https://github.com/danielvm-git/bigpowers-showcase) — a real URL shortener (CLI + SQLite) built from scratch with the full spec trail committed from day one.
+
 ---
 
 ## 🗺 How to Read This README