bigpowers 2.77.0 → 2.77.1

package/.pi/skills/migrate-spec/SKILL.md

@@ -56,13 +56,13 @@ If none found: ask the user which framework before proceeding.
 
 List every artifact found matching the detected framework. Present the list to the user:
 
-See [REFERENCE.md](REFERENCE.md) — `Detected: GSD...`
+See [REFERENCE.md](../../../skills/migrate-spec/REFERENCE.md) — `Detected: GSD...`
 
 → verify: `find . -maxdepth 4 \( -name "ROADMAP.md" -o -name "spec.md" -o -name "prd.md" -o -name "REQUIREMENTS.md" \) 2>/dev/null | grep -v ".git" | head -15`
 
 ### Step 3 — Transform (one artifact at a time, show diffs)
 
-Apply the mapping from [REFERENCE.md](./REFERENCE.md) and [REFERENCE-GSD.md](./REFERENCE-GSD.md). For each target file:
+Apply the mapping from [REFERENCE.md](../../../skills/migrate-spec/REFERENCE.md) and [REFERENCE-GSD.md](../../../skills/migrate-spec/REFERENCE-GSD.md). For each target file:
 
 1. Show what will be created or appended (title + first 20 lines).
 2. Ask: "Create this? [yes / edit / skip]"
@@ -72,25 +72,25 @@ Apply the mapping from [REFERENCE.md](./REFERENCE.md) and [REFERENCE-GSD.md](./R
 
 When source artifacts contain IDs (REQ-XX, FR-XX, UJ-XX), emit them as **first-class YAML fields** in `in_scope` entries, not YAML comments:
 
-See [REFERENCE.md](REFERENCE.md) — `# CORRECT — first-class id: field...`
+See [REFERENCE.md](../../../skills/migrate-spec/REFERENCE.md) — `# CORRECT — first-class id: field...`
 
 **When source has no IDs:** Prompt the user: "No IDs found. Assign auto-generated IDs? [yes / no]". If yes, emit `REQ-{NNN}` with `# auto-generated` annotation.
 
 **When source has MIXED IDs:** Items with IDs get `id:` fields; items without IDs receive auto-generated `REQ-NNN` entries. Document which were auto-generated in a comment block at the top of `in_scope`.
 
-See [REFERENCE.md — in_scope format with ID tracking](./REFERENCE.md#in_scope-format-with-id-tracking) for examples.
+See [REFERENCE.md — in_scope format with ID tracking](../../../skills/migrate-spec/REFERENCE.md#in_scope-format-with-id-tracking) for examples.
 
 #### Traceability Output (FR-XX, UJ-XX)
 
 When source has FR-XX or UJ-XX IDs, emit `specs/product/REQUIREMENTS_TRACE.yaml` for end-to-end requirement traceability:
 
-See [REFERENCE.md](REFERENCE.md) — `trace:...`
+See [REFERENCE.md](../../../skills/migrate-spec/REFERENCE.md) — `trace:...`
 
 **Existing trace file:** If `REQUIREMENTS_TRACE.yaml` already exists, prompt: "REQUIREMENTS_TRACE.yaml exists. [overwrite / merge / skip]"
 
 **No FR-XX/UJ-XX found:** Skip trace file; add note to state.yaml handoff: "No FR-XX/UJ-XX IDs found — traceability file skipped".
 
-See [REFERENCE.md — REQUIREMENTS_TRACE.yaml format](./REFERENCE.md#requirements_traceyaml-format) for the complete schema.
+See [REFERENCE.md — REQUIREMENTS_TRACE.yaml format](../../../skills/migrate-spec/REFERENCE.md#requirements_traceyaml-format) for the complete schema.
 
 > **HARD GATE** — Never overwrite an existing `specs/` file without explicit user confirmation. Merge into it if it exists; don't clobber.
 >
@@ -102,11 +102,11 @@ See [REFERENCE.md — REQUIREMENTS_TRACE.yaml format](./REFERENCE.md#requirement
 
 Always regenerate `specs/state.yaml` from scratch in bigpowers YAML format (see REFERENCE.md for template). The **handoff block is mandatory** and must include all four fields:
 
-See [REFERENCE.md](REFERENCE.md) — `active_flow: null...`
+See [REFERENCE.md](../../../skills/migrate-spec/REFERENCE.md) — `active_flow: null...`
 
 If no open decisions were found during migration, the `open_decisions` list may be empty with an explanatory comment:
 
-See [REFERENCE.md](REFERENCE.md) — `handoff:...`
+See [REFERENCE.md](../../../skills/migrate-spec/REFERENCE.md) — `handoff:...`
 
 → verify: `grep -q 'handoff:' specs/state.yaml && grep -q 'last_step_completed' specs/state.yaml && echo "ok" || echo "MISSING or INCOMPLETE: handoff block"`
 
@@ -116,7 +116,7 @@ See [REFERENCE.md](REFERENCE.md) — `handoff:...`
 
 Full artifact transformation rules for migrating GSD projects to bigpowers YAML layout.
 
-See [REFERENCE.md](./REFERENCE.md) for spec-kit, BMAD, learnings, and ADR/DECISION-LOG formats.
+See [REFERENCE.md](../../../skills/migrate-spec/REFERENCE.md) for spec-kit, BMAD, learnings, and ADR/DECISION-LOG formats.
 
 ---
 
@@ -162,7 +162,7 @@ Transform:
 GSD REQUIREMENTS has: REQ-XX IDs, Validated/Active/Out-of-Scope categories, traceability.
 
 Transform:
-- Preserve REQ-XX IDs as **first-class `id:` fields** in `in_scope` entries (see [REFERENCE.md — ID tracking format](./REFERENCE.md#in_scope-format-with-id-tracking))
+- Preserve REQ-XX IDs as **first-class `id:` fields** in `in_scope` entries (see [REFERENCE.md — ID tracking format](../../../skills/migrate-spec/REFERENCE.md#in_scope-format-with-id-tracking))
 - Validated requirements → `in_scope` entries with `id:`, `description:`, `source:` fields
 - Out-of-Scope → `out_of_scope` entries (preserve IDs if present)
 - Active (in-progress) → `in_scope` with status note
@@ -264,7 +264,7 @@ These GSD artifacts are not migrated — they are execution records, not plannin
 
 Transformation rules for spec-kit and BMAD projects, plus learnings to adopt and output formats.
 
-See [REFERENCE-GSD.md](./REFERENCE-GSD.md) for full GSD → bigpowers YAML mapping.
+See [REFERENCE-GSD.md](../../../skills/migrate-spec/REFERENCE-GSD.md) for full GSD → bigpowers YAML mapping.
 
 ---
 
@@ -776,7 +776,7 @@ If **no**, skip. Add note to handoff: "Methodology doc: skipped — can be added
 
 ## Artifact Mapping Summary
 
-Full mapping tables: [REFERENCE-GSD.md](./REFERENCE-GSD.md) (GSD) · [REFERENCE.md](./REFERENCE.md) (spec-kit, BMAD, learnings).
+Full mapping tables: [REFERENCE-GSD.md](../../../skills/migrate-spec/REFERENCE-GSD.md) (GSD) · [REFERENCE.md](../../../skills/migrate-spec/REFERENCE.md) (spec-kit, BMAD, learnings).
 
 | Source | Target |
 |--------|--------|
@@ -814,7 +814,7 @@ Full mapping tables: [REFERENCE-GSD.md](./REFERENCE-GSD.md) (GSD) · [REFERENCE.
 
 After migration, offer the user a brief analysis of what the source framework did that bigpowers doesn't have yet.
 
-Use the learnings table from [REFERENCE.md](./REFERENCE.md#learnings-to-adopt). Present as checkboxes so the user can decide which to adopt.
+Use the learnings table from [REFERENCE.md](../../../skills/migrate-spec/REFERENCE.md#learnings-to-adopt). Present as checkboxes so the user can decide which to adopt.
 
 → verify: `grep -c "\- \[ \]" specs/state.yaml 2>/dev/null && echo "pending items recorded" || echo "no pending items in state.yaml"`
 

package/.pi/skills/model-domain/SKILL.md

@@ -74,7 +74,7 @@ When the user states how something works, check whether the code agrees. If you
 
 ### Update specs/tech-architecture/tech-stack.md inline
 
-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).
+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](../../../skills/model-domain/CONTEXT-FORMAT.md).
 
 Don't couple `specs/tech-architecture/tech-stack.md` to implementation details. Only include terms that are meaningful to domain experts.
 
@@ -86,7 +86,7 @@ Only offer to create an ADR when all three are true:
 2. **Surprising without context** — a future reader will wonder "why did they do it this way?"
 3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
 
-If any of the three is missing, skip the ADR. Use the format in [ADR-FORMAT.md](./ADR-FORMAT.md).
+If any of the three is missing, skip the ADR. Use the format in [ADR-FORMAT.md](../../../skills/model-domain/ADR-FORMAT.md).
 
 ## Concurrency safety audit
 
@@ -212,9 +212,9 @@ _Avoid_: Client, buyer, account
 
 ## Contexts
 
-- [Ordering](./src/ordering/CONTEXT.md) — receives and tracks customer orders
-- [Billing](./src/billing/CONTEXT.md) — generates invoices and processes payments
-- [Fulfillment](./src/fulfillment/CONTEXT.md) — manages warehouse picking and shipping
+- Ordering — `src/ordering/CONTEXT.md` — receives and tracks customer orders
+- Billing — `src/billing/CONTEXT.md` — generates invoices and processes payments
+- Fulfillment — `src/fulfillment/CONTEXT.md` — manages warehouse picking and shipping
 
 ## Relationships
 

package/.pi/skills/orchestrate-project/SKILL.md

@@ -40,7 +40,7 @@ Track progress via `specs/state.yaml` `project_cycle`:
 - `handoff.next_skill`: skill for the current phase
 - On resume, read `project_cycle.current_phase` and continue from there
 
-See [REFERENCE.md](REFERENCE.md) for detailed phase specifications and gate types.
+See [REFERENCE.md](../../../skills/orchestrate-project/REFERENCE.md) for detailed phase specifications and gate types.
 
 ## How Orchestrate Works
 
@@ -58,7 +58,7 @@ See [REFERENCE.md](REFERENCE.md) for detailed phase specifications and gate type
 - **Fast-Track**: Skip negotiable gates. Use for hotfixes and minor improvements.
 - **Ad-Hoc**: Warnings only. Use for prototyping and spikes (non-production).
 
-See [REFERENCE.md](REFERENCE.md) for full mode behaviors.
+See [REFERENCE.md](../../../skills/orchestrate-project/REFERENCE.md) for full mode behaviors.
 
 ## Verification
 

package/.pi/skills/organize-workspace/SKILL.md

@@ -74,7 +74,7 @@ Do this when the repo is under Git and the cleanup surfaced **untracked** noise:
 4. **User must approve** the exact diff before editing the file.
 5. **Verify**: run `git check-ignore -v <path>` on 2–3 representative paths.
 
-See [REFERENCE.md](REFERENCE.md) for shell patterns, `.gitignore` mechanics, and safety checks.
+See [REFERENCE.md](../../../skills/organize-workspace/REFERENCE.md) for shell patterns, `.gitignore` mechanics, and safety checks.
 
 
 

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

@@ -81,7 +81,7 @@ After writing `specs/REFACTOR_LATEST.md`, suggest running `kickoff-branch` next
 
 <!-- story: e35s10 -->
 
-- [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
+- [Fowler's Refactoring Catalog](https://github.com/danielvm-git/bigpowers/blob/main/docs/references/fowler.md) — canonical refactoring vocabulary and code-smell taxonomy
+- [Beck's Tidy First?](https://github.com/danielvm-git/bigpowers/blob/main/docs/references/kent-beck.md) — structural change before behavioral change
 
 ## Verify

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

@@ -17,7 +17,7 @@ Synthesize the conversation context into `specs/release-plan.yaml` (index) and s
 |------|---------|
 | `specs/release-plan.yaml` | `release.version`, semver bump hint, WSJF-ordered epic list with `id`, `capsule_dir`, `wsjf`, `bcps` — **no story status** |
 | `specs/epics/eNN-<slug>/epic.yaml` | Epic manifest: `id`, `title`, `wsjf`, `total_bcps`, `status`, `stories[]` list |
-| `specs/epics/eNN-<slug>/eNNsYY-<slug>.md` | Story spec in [countable-story-format.md](file:///Users/danielvm/Developer/bigpowers/countable-story-format.md) with 20 sections and Gherkin acceptance criteria |
+| `specs/epics/eNN-<slug>/eNNsYY-<slug>.md` | Story spec in [countable-story-format.md](https://github.com/danielvm-git/bigpowers/blob/main/docs/countable-story-format.md) with 20 sections and Gherkin acceptance criteria |
 | `specs/epics/eNN-<slug>/eNNsYY-tasks.yaml` | Decoupled task checklist with `verify:` commands per task |
 | `specs/execution-status.yaml` | Flat key-value store for story status (`eNNsYY: todo`) |
 
@@ -102,7 +102,7 @@ stories:
 ```
 ### 6. Save story specs (countable-story-format .md)
 
-Each story becomes a standalone `.md` file following [countable-story-format.md](file:///Users/danielvm/Developer/bigpowers/countable-story-format.md). Minimum: maturity 3 (Countable) with all 20 sections present. Acceptance criteria in §17 use Gherkin scenarios.
+Each story becomes a standalone `.md` file following [countable-story-format.md](https://github.com/danielvm-git/bigpowers/blob/main/docs/countable-story-format.md). Minimum: maturity 3 (Countable) with all 20 sections present. Acceptance criteria in §17 use Gherkin scenarios.
 ### 7. Save decoupled task files (`-tasks.yaml`)
 
 Each story has a decoupled `-tasks.yaml` with implementation steps:

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

@@ -45,7 +45,7 @@ If this plan touches an existing module, run `assess-impact` first to understand
 
 2. **Draft steps** — Break implementation into the smallest possible steps where each step leaves the codebase working, has one observable outcome, and can be verified with a single command. Red-flag check: name any rationalization you caught before moving to step 3.
 
-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. Each task should also include an `allure:` block to drive test reporting: `severity:` maps risk to Allure severity (`P0→critical`, `P1→high`, `P2→normal`, `P3→minor`), and `categories:` is a list of relevant tags like `"Security Review"`, wave names, or test categories (see REFERENCE.md for the full template).
+3. **Write capsule story spec + tasks** — Output two files inside the active epic capsule. See [REFERENCE.md](../../../skills/plan-work/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. Each task should also include an `allure:` block to drive test reporting: `severity:` maps risk to Allure severity (`P0→critical`, `P1→high`, `P2→normal`, `P3→minor`), and `categories:` is a list of relevant tags like `"Security Review"`, wave names, or test categories (see REFERENCE.md for the full template).
 
    **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:
 
@@ -58,7 +58,7 @@ If this plan touches an existing module, run `assess-impact` first to understand
 
    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.
+4. **Verify step format** — Every step MUST follow: `N. <What to do> → verify: <runnable command>`. See [REFERENCE.md](../../../skills/plan-work/REFERENCE.md) for good/bad examples.
 
 4a. **Cross-artifact consistency pass (HARD GATE — e45s04)** — Before handoff, run:
 

package/.pi/skills/publish-package/SKILL.md

@@ -33,41 +33,41 @@ If no manifest is found, prompt the user to specify the type or pass `--type <np
 Before attempting any publish, run all applicable checks:
 
 **npm (`package.json`):**
-See [REFERENCE.md](REFERENCE.md)
+See [REFERENCE.md](../../../skills/publish-package/REFERENCE.md)
 
 **crates.io (`Cargo.toml`):**
-See [REFERENCE.md](REFERENCE.md)
+See [REFERENCE.md](../../../skills/publish-package/REFERENCE.md)
 
 **PyPI (`setup.py` / `pyproject.toml`):**
-See [REFERENCE.md](REFERENCE.md)
+See [REFERENCE.md](../../../skills/publish-package/REFERENCE.md)
 
 ### 3. Run publish
 
 After all prerequisite checks pass, run the registry-specific command:
 
-See [REFERENCE.md](REFERENCE.md)
+See [REFERENCE.md](../../../skills/publish-package/REFERENCE.md)
 
 ### 4. Verify publish success
 
 After publish, confirm the version appears on the registry:
 
-See [REFERENCE.md](REFERENCE.md)
+See [REFERENCE.md](../../../skills/publish-package/REFERENCE.md)
 
 ### 5. Error handling
 
 On failure, surface actionable hints:
 
-See [REFERENCE.md](REFERENCE.md)
+See [REFERENCE.md](../../../skills/publish-package/REFERENCE.md)
 
 ### 6. Dry-run mode (`--dry-run`)
 
 Run `--dry-run` to verify all prerequisites without actually publishing:
 
-See [REFERENCE.md](REFERENCE.md)
+See [REFERENCE.md](../../../skills/publish-package/REFERENCE.md)
 
 ### 7. Dry-run mode per registry
 
-See [REFERENCE.md](REFERENCE.md)
+See [REFERENCE.md](../../../skills/publish-package/REFERENCE.md)
 
 ## Verify
 

package/.pi/skills/release-branch/SKILL.md

@@ -120,7 +120,7 @@ mv specs/epics/eNN-slug specs/epics/archive/
 
 ### 7b. CI verification & agent lock release (e39s02)
 
-> **HARD GATE** — Do NOT declare success until CI completes. **Three-independent-facts** (e45s15): commit landed, workflow green, registry visible — see [REFERENCE.md](REFERENCE.md#three-independent-facts-release).
+> **HARD GATE** — Do NOT declare success until CI completes. **Three-independent-facts** (e45s15): commit landed, workflow green, registry visible — see [REFERENCE.md](../../../skills/release-branch/REFERENCE.md#three-independent-facts-release).
 
 ```bash
 bash scripts/wait-for-ci.sh --timeout 600 --interval 30
@@ -131,7 +131,7 @@ bash scripts/wait-for-ci.sh --timeout 600 --interval 30
 
 ### 8. Clean up & return
 
-Worktree prune, branch delete, `git checkout main`. Cycle-time: see [REFERENCE.md](REFERENCE.md#cycle-time).
+Worktree prune, branch delete, `git checkout main`. Cycle-time: see [REFERENCE.md](../../../skills/release-branch/REFERENCE.md#cycle-time).
 
 Report: "Branch released."
 

package/.pi/skills/research-first/SKILL.md

@@ -52,7 +52,7 @@ If opensrc is not installed or the package is not cached, fall through to web do
 
 → verify: `grep -c "Prior Art" specs/product/SCOPE_LATEST.yaml specs/release-plan.yaml + epic shards 2>/dev/null | awk '{s+=$1} END {if(s>0) print "OK"; else print "MISSING"}'`
 
-See [REFERENCE.md](REFERENCE.md) for search commands and registry checklist.
+See [REFERENCE.md](../../../skills/research-first/REFERENCE.md) for search commands and registry checklist.
 
 ---
 

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

@@ -30,7 +30,7 @@ description: "Eval-Driven Development — define capability and regression evals
 
 ## Artefact
 
-`specs/verifications/eNNsYY-eval-report.md` — see [REFERENCE.md](REFERENCE.md) for template. Eval reports are stored alongside verification evidence in `specs/verifications/`, keyed by story ID for traceability.
+`specs/verifications/eNNsYY-eval-report.md` — see [REFERENCE.md](../../../skills/run-evals/REFERENCE.md) for template. Eval reports are stored alongside verification evidence in `specs/verifications/`, keyed by story ID for traceability.
 
 ## Verify
 

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

@@ -103,9 +103,9 @@ Each finding: **`File:Line` — Severity — Category**
 
 ## Reference files
 
-- [Vuln categories](REFERENCE-vuln-categories.md) — detection guidance per vuln type
-- [False positives](REFERENCE-false-positives.md) — hard exclusions + precedent
-- [Confidence rubric](REFERENCE-confidence-rubric.md) — scoring methodology (0–10)
+- [Vuln categories](../../../skills/security-review/REFERENCE-vuln-categories.md) — detection guidance per vuln type
+- [False positives](../../../skills/security-review/REFERENCE-false-positives.md) — hard exclusions + precedent
+- [Confidence rubric](../../../skills/security-review/REFERENCE-confidence-rubric.md) — scoring methodology (0–10)
 
 ## Verify
 

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

@@ -37,11 +37,11 @@ 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 for project-local tools? (Cursor, OpenCode, Cline, Aider, Codex CLI)" If yes, generate AGENTS.md spine artifacts per [REFERENCE.md](REFERENCE.md) §Local tool wiring and §AGENTS.md spine. If no, skip — standard seed output unchanged (no AGENTS.md spine unless opted in).
+8. **Local tool wiring (optional)** — "Wire bigpowers for project-local tools? (Cursor, OpenCode, Cline, Aider, Codex CLI)" If yes, generate AGENTS.md spine artifacts per [REFERENCE.md](../../../skills/seed-conventions/REFERENCE.md) §Local tool wiring and §AGENTS.md spine. If no, skip — standard seed output unchanged (no AGENTS.md spine unless opted in).
 
 ## Generate files
 
-After the interview, generate each file using the templates in [REFERENCE.md](REFERENCE.md):
+After the interview, generate each file using the templates in [REFERENCE.md](../../../skills/seed-conventions/REFERENCE.md):
 - `AGENTS.md` — from `docs/templates/AGENTS.md` Reach Template (canonical spine source)
 - `CLAUDE.md` — symlink to `AGENTS.md` (copy fallback on Windows when symlink fails)
 - `GEMINI.md` — symlink to `AGENTS.md` when Gemini wiring opted in
@@ -81,7 +81,7 @@ Skills that write into `CLAUDE.md` or `AGENTS.md` MUST use **fenced HTML comment
 
 **Merge rule:** On update, replace only the content *between* matching `BEGIN`/`END` pairs. If a marker pair is missing, append a new fenced block at the end of the file — never rewrite the whole file.
 
-**Standard marker IDs** for seeded projects (see [REFERENCE.md](REFERENCE.md) § Fenced markers):
+**Standard marker IDs** for seeded projects (see [REFERENCE.md](../../../skills/seed-conventions/REFERENCE.md) § Fenced markers):
 
 | Marker ID | Owner skill | Purpose |
 |-----------|-------------|---------|

package/.pi/skills/smoke-test/SKILL.md

@@ -21,7 +21,7 @@ Can be run standalone for quick health checks or chained as the final step of th
 
 Smoke checks are defined in `smoke-checks.yaml` at the project root:
 
-See [REFERENCE.md](REFERENCE.md)
+See [REFERENCE.md](../../../skills/smoke-test/REFERENCE.md)
 
 Checks can also be specified inline via environment variables or CLI arguments for ad-hoc use.
 
@@ -40,21 +40,21 @@ Checks can also be specified inline via environment variables or CLI arguments f
 
 ### 1. Load smoke checks
 
-See [REFERENCE.md](REFERENCE.md)
+See [REFERENCE.md](../../../skills/smoke-test/REFERENCE.md)
 
 ### 2. Run each check
 
 For each check in the configuration, perform an HTTP request:
 
-See [REFERENCE.md](REFERENCE.md)
+See [REFERENCE.md](../../../skills/smoke-test/REFERENCE.md)
 
 ### 3. Assert results
 
-See [REFERENCE.md](REFERENCE.md)
+See [REFERENCE.md](../../../skills/smoke-test/REFERENCE.md)
 
 ### 4. Generate report
 
-See [REFERENCE.md](REFERENCE.md)
+See [REFERENCE.md](../../../skills/smoke-test/REFERENCE.md)
 
 ## Integration with deploy skill
 

package/.pi/skills/stocktake-skills/SKILL.md

@@ -58,7 +58,7 @@ Timing data is populated by `scripts/bp-timing.sh start|end <skill>` calls withi
 
 → verify: `test -f specs/STOCKTAKE-*.md && bash scripts/validate-skill-catalog.sh && echo OK || echo MISSING`
 
-See [REFERENCE.md](REFERENCE.md) for checklist.
+See [REFERENCE.md](../../../skills/stocktake-skills/REFERENCE.md) for checklist.
 
 ---
 

package/.pi/skills/using-bigpowers/SKILL.md

@@ -77,7 +77,7 @@ UTILITY     terse-mode / craft-skill / edit-document (any phase)
 
 If you work alone and do not want PR ceremony every task:
 
-1. Read [profiles/solo-git.md](../profiles/solo-git.md).
+1. Read [profiles/solo-git.md](../../../profiles/solo-git.md).
 2. Register with `compose-workflow` → `specs/WORKFLOW-solo-git.md`.
 3. Ship with `release-branch` in **solo-local** mode (`land-branch.sh`), not `gh pr create`.
 

package/.pi/skills/validate-contracts/SKILL.md

@@ -28,13 +28,13 @@ Three modes of validation:
 
 All contract files live in `specs/contracts/` and use YAML:
 
-See [REFERENCE.md](REFERENCE.md) for examples.
+See [REFERENCE.md](../../../skills/validate-contracts/REFERENCE.md) for examples.
 
 ### 1. API Response Contracts (`--schema`)
 
 Define expected API response shapes and validate live endpoints against them:
 
-See [REFERENCE.md](REFERENCE.md) for examples.
+See [REFERENCE.md](../../../skills/validate-contracts/REFERENCE.md) for examples.
 
 Usage:
 
@@ -48,21 +48,21 @@ validate-contracts --schema specs/contracts/users.schema.yaml --url https://api.
 
 Assert that two data sources share a consistent set of keys:
 
-See [REFERENCE.md](REFERENCE.md) for examples.
+See [REFERENCE.md](../../../skills/validate-contracts/REFERENCE.md) for examples.
 
 Usage:
 
-See [REFERENCE.md](REFERENCE.md) for examples.
+See [REFERENCE.md](../../../skills/validate-contracts/REFERENCE.md) for examples.
 
 ### 3. Data Shape Contracts (`--shape`)
 
 Validate that a data file matches expected column types and constraints:
 
-See [REFERENCE.md](REFERENCE.md) for examples.
+See [REFERENCE.md](../../../skills/validate-contracts/REFERENCE.md) for examples.
 
 Usage:
 
-See [REFERENCE.md](REFERENCE.md) for examples.
+See [REFERENCE.md](../../../skills/validate-contracts/REFERENCE.md) for examples.
 
 ## Process
 

package/.pi/skills/verify-work/SKILL.md

@@ -137,7 +137,7 @@ for p in specs/conventions-wiki/*.md; do [ "$(basename "$p")" = "index.md" ]&&co
 
 ## --cli mode
 
-CLI tools: use `--cli` when no server process. Binary detect + checklist: [REFERENCE.md](REFERENCE.md#cli-mode).
+CLI tools: use `--cli` when no server process. Binary detect + checklist: [REFERENCE.md](../../../skills/verify-work/REFERENCE.md#cli-mode).
 
 ## Verify
 

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

@@ -42,25 +42,25 @@ If no manifest is found, prompt the user to specify the type or pass `--type <ru
 Create `.github/workflows/ci.yaml` with standard steps derived from the project type and its manifest:
 
 **Rust template (`Cargo.toml`):**
-See [REFERENCE.md](REFERENCE.md)
+See [REFERENCE.md](../../../skills/wire-ci/REFERENCE.md)
 
 **Node template (`package.json`):**
-See [REFERENCE.md](REFERENCE.md)
+See [REFERENCE.md](../../../skills/wire-ci/REFERENCE.md)
 
 **Python template (`setup.py` / `pyproject.toml`):**
-See [REFERENCE.md](REFERENCE.md)
+See [REFERENCE.md](../../../skills/wire-ci/REFERENCE.md)
 
 **Go template (`go.mod`):**
-See [REFERENCE.md](REFERENCE.md)
+See [REFERENCE.md](../../../skills/wire-ci/REFERENCE.md)
 
 **C/C++ template (`CMakeLists.txt`):**
-See [REFERENCE.md](REFERENCE.md)
+See [REFERENCE.md](../../../skills/wire-ci/REFERENCE.md)
 
 ### 3. Generate release workflow (if semantic-release detected)
 
 If the project has semantic-release configured (in `package.json`, `.releaserc`, or `release.config.js`), also generate `.github/workflows/release.yaml`:
 
-See [REFERENCE.md](REFERENCE.md)
+See [REFERENCE.md](../../../skills/wire-ci/REFERENCE.md)
 
 > **NPM_TOKEN is required** for publishing to npm. Without it, semantic-release will fail at the publish step. See `--validate` to check this.
 
@@ -68,7 +68,7 @@ See [REFERENCE.md](REFERENCE.md)
 
 Run `wire-ci --validate` to check all generated workflow files:
 
-See [REFERENCE.md](REFERENCE.md)
+See [REFERENCE.md](../../../skills/wire-ci/REFERENCE.md)
 
 **Exit codes:**
 - `0` — all checks pass (no errors)
@@ -79,7 +79,7 @@ See [REFERENCE.md](REFERENCE.md)
 
 Attempt to run the generated workflows locally to catch errors before push:
 
-See [REFERENCE.md](REFERENCE.md)
+See [REFERENCE.md](../../../skills/wire-ci/REFERENCE.md)
 
 > **act** runs workflows in a local Docker environment — the most accurate pre-push validation.
 > **gh workflow run** sends the workflow to GitHub but doesn't execute locally — useful for checking YAML parsing but not for testing the actual steps.

package/.pi/skills/write-document/SKILL.md

@@ -46,7 +46,7 @@ Write the document focusing on "Expert Collaboration":
 ### Quick README (Project READMEs only)
 
 1. Ask: "Project name? One-sentence description?"
-2. Generate `README.md` at project root using the template in [REFERENCE.md](REFERENCE.md) — no TOC, no second interview round.
+2. Generate `README.md` at project root using the template in [REFERENCE.md](../../../skills/write-document/REFERENCE.md) — no TOC, no second interview round.
 3. Fill gaps from `CLAUDE.md` commands if available; use `TODO` markers otherwise.
 4. Output and suggest `edit-document` for polish.
 
@@ -220,7 +220,7 @@ Auto-fill from CLAUDE.md `Test` and `Lint` commands.
 ```markdown
 ## Changelog
 
-See [CHANGELOG.md](CHANGELOG.md) or [Releases](https://github.com/user/repo/releases).
+See [CHANGELOG.md](../../CHANGELOG.md) or [Releases](https://github.com/user/repo/releases).
 ```
 
 ### 13. Links
@@ -237,7 +237,7 @@ See [CHANGELOG.md](CHANGELOG.md) or [Releases](https://github.com/user/repo/rele
 ```markdown
 ## License
 
-MIT — see [LICENSE](LICENSE) for details.
+MIT — see [LICENSE](../../LICENSE) for details.
 ```
 
 Detect from CLAUDE.md or project LICENSE file.

package/CHANGELOG.md

@@ -1,3 +1,10 @@
+## [2.77.1](https://github.com/danielvm-git/bigpowers/compare/v2.77.0...v2.77.1) (2026-07-19)
+
+
+### Bug Fixes
+
+* **scripts:** address PR [#79](https://github.com/danielvm-git/bigpowers/issues/79) dual-blind review findings ([#80](https://github.com/danielvm-git/bigpowers/issues/80)) ([a03ada9](https://github.com/danielvm-git/bigpowers/commit/a03ada962b3c6ccb9721563664c5e424c145083b)), closes [#78](https://github.com/danielvm-git/bigpowers/issues/78) [#78](https://github.com/danielvm-git/bigpowers/issues/78)
+
 # [2.77.0](https://github.com/danielvm-git/bigpowers/compare/v2.76.3...v2.77.0) (2026-07-13)
 
 

package/package.json

@@ -1,10 +1,10 @@
 {
   "name": "bigpowers",
-  "version": "2.77.0",
+  "version": "2.77.1",
   "description": "73 agent skills synthesizing 17 years of software engineering discipline into a prescriptive methodology for solo developers",
   "main": "index.js",
   "scripts": {
-    "compliance": "bash scripts/audit-compliance.sh specs/verifications/features && bash scripts/validate-doctrine.sh",
+    "compliance": "bash scripts/audit-compliance.sh specs/verifications/features && bash scripts/validate-doctrine.sh && python3 scripts/check-skill-links.py",
     "doctrine": "bash scripts/validate-doctrine.sh",
     "sync": "bash scripts/sync-skills.sh",
     "validate-specs": "bash scripts/validate-specs-yaml.sh",
@@ -15,7 +15,8 @@
     "dashboard:web": "node dashboard/bin/dashboard.js --web",
     "site:dev": "cd website && npm run dev",
     "site:build": "cd website && npm run build",
-    "site:preview": "cd website && npm run preview"
+    "site:preview": "cd website && npm run preview",
+    "check:skill-links": "python3 scripts/check-skill-links.py"
   },
   "keywords": [
     "skills",

package/scripts/adapters/pi.sh

@@ -17,7 +17,7 @@ render_skill() {
       echo "description: \"$IR_DESC_ESCAPED\""
       echo "---"
       echo ""
-      echo "$IR_BODY"
+      echo "${IR_BODY_SKILL:-$IR_BODY}"
     } > "${PI_SKILLS}/$IR_NAME/SKILL.md"
   }
 
@@ -45,6 +45,9 @@ if [[ ! -t 0 ]]; then
     IR_MODEL=$(echo "$JSON_INPUT" | jq -r '.model')
     IR_DESCRIPTION=$(echo "$JSON_INPUT" | jq -r '.description')
     IR_BODY=$(echo "$JSON_INPUT" | jq -r '.body')
+    # Skill files get link-rewritten bodies (relative links repointed from
+    # .pi/skills/<name>/ to the shipped source tree); prompts keep the raw body.
+    IR_BODY_SKILL=$(echo "$JSON_INPUT" | jq -r '.body_pi_skill // .body')
     IR_DESC_ESCAPED=$(echo "$IR_DESCRIPTION" | sed 's/\\/\\\\/g; s/\"/\\"/g')
     render_skill
   fi