bigpowers 2.86.4 → 2.86.5

package/.pi/prompts/harden-vps.md

@@ -1,15 +1,15 @@
 ---
 name: harden-vps
-description: "Harden a production Linux VPS for BigBase across three layers — BigBase app (systemd hardening, monitoring alerts, backup automation), Ubuntu OS (UFW firewall, fail2ban SSH, unattended-upgrades, SSH hardening), and Contabo VPS (health checks, daily backups, monthly snapshots). Use when the user wants to secure a production server, harden a VPS, audit server security, or mentions production hardening, VPS security, or harden the server."
+description: "Harden a production Linux VPS for your application across three layers — application (systemd hardening, monitoring alerts, backup automation), Ubuntu OS (UFW firewall, fail2ban SSH, unattended-upgrades, SSH hardening), and VPS provider (health checks, daily backups, monthly snapshots). Use when the user wants to secure a production server, harden a VPS, audit server security, or mentions production hardening, VPS security, or harden the server."
 ---
 
 # Harden VPS
 
-Three-layer production hardening for BigBase on Contabo VPS. Each layer independently verifiable. Apply OS first (firewall blocks attacks immediately), then BigBase (alerts + backups), then Contabo (snapshots). See [REFERENCE.md](REFERENCE.md) for full script bodies, systemd unit template, and gotchas.
+Three-layer production hardening for a self-hosted app on any VPS. Each layer independently verifiable. Apply OS first (firewall blocks attacks immediately), then your application (alerts + backups), then your VPS provider (snapshots). See [REFERENCE.md](REFERENCE.md) for full script bodies, systemd unit template, and gotchas.
 
 ## Quick start
 
-SSH as root into the VPS. Find credentials in the Contabo Customer Control Panel.
+SSH as root into the VPS. Find credentials in the your VPS provider Customer Control Panel.
 
 > **HARD GATE** — Run `ufw status` first. No firewall = layer 1 takes priority over everything.
 
@@ -34,21 +34,21 @@ apt install -y unattended-upgrades && dpkg-reconfigure -plow unattended-upgrades
 # SSH: PermitRootLogin no, PasswordAuthentication no, PubkeyAuthentication yes
 # → verify: sshd -T | grep -E 'permitrootlogin no|passwordauthentication no'
 
-# Deploy healthcheck.sh → /opt/bigbase/scripts/healthcheck.sh
-# Crontab: */5 * * * * /opt/bigbase/scripts/healthcheck.sh
+# Deploy healthcheck.sh → /opt/your-app/scripts/healthcheck.sh
+# Crontab: */5 * * * * /opt/your-app/scripts/healthcheck.sh
 ```
 
-## Layer 2 — BigBase application
+## Layer 2 — applicationlication
 
 ```bash
-# systemd: User=bigbase, NoNewPrivileges=yes, ProtectSystem=full,
+# systemd: User=your-app, NoNewPrivileges=yes, ProtectSystem=full,
 #   ProtectKernelTunables=yes, ProtectKernelModules=yes,
 #   ProtectControlGroups=yes, RestrictAddressFamilies=AF_INET AF_INET6,
 #   RestrictRealtime=yes, PrivateTmp=yes, LimitNOFILE=65536
-# → verify: systemctl show bigbase -p NoNewPrivileges -p ProtectSystem -p User
+# → verify: systemctl show your-app -p NoNewPrivileges -p ProtectSystem -p User
 
-# Alerts (BigBase requires auth; insert via SQLite)
-sqlite3 /opt/bigbase/data/bigbase.db "
+# Alerts (your application requires auth; insert via SQLite)
+sqlite3 /opt/your-app/data/your-app.db "
 INSERT INTO monitoring_alerts (id,name,metric,threshold,operator,enabled,duration_seconds)
 VALUES ('a1','Disk >80%','disk_used_percent',80,'gt',1,300);
 INSERT INTO monitoring_alerts (id,name,metric,threshold,operator,enabled,duration_seconds)
@@ -56,14 +56,14 @@ VALUES ('a2','CPU >90%','cpu_percent',90,'gt',1,60);
 INSERT INTO monitoring_alerts (id,name,metric,threshold,operator,enabled,duration_seconds)
 VALUES ('a3','RAM >85%','mem_used_percent',85,'gt',1,120);
 "
-systemctl restart bigbase
+systemctl restart your-app
 
 # Backup crontab (root):
-# 0 2 * * * cp /opt/bigbase/data/bigbase.db /backup/bigbase-$(date +\%Y\%m\%d).db
-# 0 3 * * * find /backup/ -name "bigbase-*.db" -mtime +90 -delete
+# 0 2 * * * cp /opt/your-app/data/your-app.db /backup/your-app-$(date +\%Y\%m\%d).db
+# 0 3 * * * find /backup/ -name "your-app-*.db" -mtime +90 -delete
 ```
 
-## Layer 3 — Contabo VPS
+## Layer 3 — VPS provider
 
 ```bash
 # cntb CLI
@@ -71,14 +71,14 @@ curl -sL "$(curl -sL https://api.github.com/repos/contabo/cntb/releases/latest \
   | grep browser_download_url.*linux_amd64.tar.gz | head -1 | cut -d'"' -f4)" \
   | tar xz -C /usr/local/bin
 
-# Snapshot script → /opt/bigbase/scripts/contabo-snapshot.sh (reads from /opt/bigbase/.env)
-# Credentials as env vars in /opt/bigbase/.env (deployed by GitHub Actions):
+# Snapshot script → /opt/your-app/scripts/contabo-snapshot.sh (reads from /opt/your-app/.env)
+# Credentials as env vars in /opt/your-app/.env (deployed by GitHub Actions):
 #   CONTABO_CLIENT_ID, CONTABO_CLIENT_SECRET, CONTABO_API_USER, CONTABO_API_PASSWORD
-# Crontab: 0 4 1 * * /opt/bigbase/scripts/contabo-snapshot.sh
+# Crontab: 0 4 1 * * /opt/your-app/scripts/contabo-snapshot.sh
 
 # > HARD GATE — Snapshot cron silently fails until env vars are set in .env.
-# Credentials source: Contabo Customer Panel → API Details.
-# Local dev: add to .envrc. Production: GitHub Secrets → deploy → /opt/bigbase/.env
+# Credentials source: your VPS provider Customer Panel → API Details.
+# Local dev: add to .envrc. Production: GitHub Secrets → deploy → /opt/your-app/.env
 ```
 
 ## CRITICAL GOTCHAS
@@ -86,7 +86,7 @@ curl -sL "$(curl -sL https://api.github.com/repos/contabo/cntb/releases/latest \
 1. **Shell escaping in Orca terminals:** `$VAR`, `$(…)`, and `%` get eaten by the local shell. Always use base64: `echo '<base64>' | base64 -d > script.sh`
 2. **Crontab `%`:** cron interprets `%` as newline. Escape as `\%` in `$(date +\%Y\%m\%d)`
 3. **fail2ban exit 255:** means a jail references a missing log file. Remove the broken jail, restart.
-4. **BigBase alerts need auth:** POST to `/api/monitoring/alerts` requires Bearer token. Workaround: insert directly into SQLite, then restart BigBase.
+4. **your application alerts need auth:** POST to `/api/monitoring/alerts` requires Bearer token. Workaround: insert directly into SQLite, then restart your application.
 
 ## Verify all 8 gates
 
@@ -95,10 +95,10 @@ ufw status|grep -q active||echo FAIL:ufw
 fail2ban-client status sshd>/dev/null 2>&1||echo FAIL:fail2ban
 systemctl is-active unattended-upgrades|grep -q active||echo FAIL:unattended
 sshd -T|grep -q 'permitrootlogin no'||echo FAIL:sshd
-systemctl show bigbase -p NoNewPrivileges|grep -q yes||echo FAIL:systemd
-systemctl is-active bigbase|grep -q active||echo FAIL:bigbase
-sqlite3 /opt/bigbase/data/bigbase.db "SELECT count(*) FROM monitoring_alerts"|grep -q 3||echo FAIL:alerts
-crontab -l|grep -q healthcheck&&crontab -l|grep -q bigbase.db&&crontab -l|grep -q contabo-snapshot||echo FAIL:crontab
+systemctl show your-app -p NoNewPrivileges|grep -q yes||echo FAIL:systemd
+systemctl is-active your-app|grep -q active||echo FAIL:your-app
+sqlite3 /opt/your-app/data/your-app.db "SELECT count(*) FROM monitoring_alerts"|grep -q 3||echo FAIL:alerts
+crontab -l|grep -q healthcheck&&crontab -l|grep -q your-app.db&&crontab -l|grep -q contabo-snapshot||echo FAIL:crontab
 echo ALL 8 GATES PASSED
 ```
 
@@ -110,47 +110,47 @@ echo ALL 8 GATES PASSED
 
 ## Health check script
 
-Deploy to `/opt/bigbase/scripts/healthcheck.sh`:
+Deploy to `/opt/your-app/scripts/healthcheck.sh`:
 
 ```bash
 #!/bin/bash
-LOG=/var/log/bigbase/health.log
-mkdir -p /var/log/bigbase
+LOG=/var/log/your-app/health.log
+mkdir -p /var/log/your-app
 DISK=$(df / | awk 'NR==2 {print $5}' | tr -d '%')
 RAM=$(free | awk '/Mem:/ {printf "%.0f", $3/$2*100}')
 NOW=$(date -Iseconds)
 [ "$DISK" -gt 85 ] && echo "$NOW ALERT: Disk ${DISK}%" >> "$LOG"
 [ "$RAM" -gt 90 ]   && echo "$NOW ALERT: RAM ${RAM}%" >> "$LOG"
-systemctl is-active --quiet bigbase || { echo "$NOW ALERT: BigBase DOWN" >> "$LOG"; systemctl restart bigbase; }
+systemctl is-active --quiet your-app || { echo "$NOW ALERT: your application DOWN" >> "$LOG"; systemctl restart your-app; }
 [ -f /var/run/reboot-required ] && echo "$NOW WARN: kernel reboot pending" >> "$LOG"
 ```
 
-Make executable: `chmod +x /opt/bigbase/scripts/healthcheck.sh`
+Make executable: `chmod +x /opt/your-app/scripts/healthcheck.sh`
 
-## BigBase systemd unit
+## your application systemd unit
 
-Full hardened unit at `/etc/systemd/system/bigbase.service`:
+Full hardened unit at `/etc/systemd/system/your-app.service`:
 
 ```ini
 [Unit]
-Description=BigBase BaaS Platform
-Documentation=https://github.com/danielvm-git/bigbase
+Description=your application BaaS Platform
+Documentation=https://github.com/example-org/example-app
 After=network.target caddy.service
 Wants=caddy.service
 
 [Service]
 Type=simple
-User=bigbase
-Group=bigbase
-WorkingDirectory=/opt/bigbase
-ExecStart=/opt/bigbase/bin/bigbase serve \
+User=your-app
+Group=your-app
+WorkingDirectory=/opt/your-app
+ExecStart=/opt/your-app/bin/your-app serve \
     --port 8080 \
-    --db /opt/bigbase/data/bigbase.db \
+    --db /opt/your-app/data/your-app.db \
     --sites-domain <your-domain.example.com>
-EnvironmentFile=-/opt/bigbase/.env
-Environment=BIGBASE_HOME=/opt/bigbase
-Environment=HOME=/opt/bigbase
-Environment=NPM_CONFIG_CACHE=/opt/bigbase/.npm
+EnvironmentFile=-/opt/your-app/.env
+Environment=APP_HOME=/opt/your-app
+Environment=HOME=/opt/your-app
+Environment=NPM_CONFIG_CACHE=/opt/your-app/.npm
 Environment=PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
 Restart=always
 RestartSec=5
@@ -167,11 +167,11 @@ ProtectKernelModules=yes
 ProtectControlGroups=yes
 RestrictAddressFamilies=AF_INET AF_INET6
 RestrictRealtime=yes
-ReadWritePaths=/opt/bigbase/data
-ReadWritePaths=/opt/bigbase/backups
-ReadWritePaths=/opt/bigbase/secrets
-ReadWritePaths=/opt/bigbase/.npm
-ReadWritePaths=/opt/bigbase/logs
+ReadWritePaths=/opt/your-app/data
+ReadWritePaths=/opt/your-app/backups
+ReadWritePaths=/opt/your-app/secrets
+ReadWritePaths=/opt/your-app/.npm
+ReadWritePaths=/opt/your-app/logs
 LimitNOFILE=65536
 
 [Install]
@@ -191,17 +191,20 @@ bantime = 3600
 findtime = 600
 ```
 
-Note: BigBase auth jail deferred — BigBase logs to journald, not a file. To enable, use `backend = systemd` with a journald filter.
+Note: your application auth jail deferred — your application logs to journald, not a file. To enable, use `backend = systemd` with a journald filter.
 
-## contabo-snapshot.sh
+## provider-snapshot.sh — worked example (Contabo API)
 
-Deploy to `/opt/bigbase/scripts/contabo-snapshot.sh`. Reads credentials from `/opt/bigbase/.env` (same file used by BigBase systemd unit):
+> Snapshot APIs are provider-specific. This is one worked example, not a
+> bigpowers default; swap the auth and endpoint calls for your own provider.
+
+Deploy to `/opt/your-app/scripts/contabo-snapshot.sh`. Reads credentials from `/opt/your-app/.env` (same file used by your application systemd unit):
 
 ```bash
 #!/bin/bash
 set -e
-LOG=/var/log/bigbase/snapshot.log
-ENVFILE=/opt/bigbase/.env
+LOG=/var/log/your-app/snapshot.log
+ENVFILE=/opt/your-app/.env
 INSTANCE_ID=<your-contabo-instance-id>
 
 [ -f "$ENVFILE" ] || { echo "$(date -Iseconds) ERROR: $ENVFILE missing" >> "$LOG"; exit 1; }
@@ -230,9 +233,9 @@ echo >> "$LOG"
 echo "$(date -Iseconds) Snapshot requested for $INSTANCE_ID" >> "$LOG"
 ```
 
-## Contabo credentials
+## your VPS provider credentials
 
-Add to `/opt/bigbase/.env` (same file used by BigBase systemd unit, deployed by GitHub Actions):
+Add to `/opt/your-app/.env` (same file used by your application systemd unit, deployed by GitHub Actions):
 
 ```
 CONTABO_CLIENT_ID=
@@ -241,13 +244,13 @@ CONTABO_API_USER=
 CONTABO_API_PASSWORD=
 ```
 
-Source: Contabo Customer Control Panel → API Details. ClientId and ClientSecret are generated there. API User is your email. API Password is set separately in the panel.
+Source: your VPS provider Customer Control Panel → API Details. ClientId and ClientSecret are generated there. API User is your email. API Password is set separately in the panel.
 
-**Pipeline:** GitHub Secrets → deploy workflow → `/opt/bigbase/.env` on VPS. For local dev (`cntb get instances`), add to `.envrc`.
+**Pipeline:** GitHub Secrets → deploy workflow → `/opt/your-app/.env` on VPS. For local dev (`cntb get instances`), add to `.envrc`.
 
-## Contabo instance info template
+## your VPS provider instance info template
 
-Fill in your instance details from the Contabo Customer Control Panel:
+Fill in your instance details from the your VPS provider Customer Control Panel:
 
 ```
 IP:           <your-instance-ip>
@@ -259,7 +262,7 @@ Default user: root
 Customer ID:  <your-customer-id>
 ```
 
-## BigBase monitoring alert SQL
+## your application monitoring alert SQL
 
 ```sql
 INSERT INTO monitoring_alerts (id, name, metric, threshold, operator, enabled, duration_seconds)
@@ -272,7 +275,7 @@ INSERT INTO monitoring_alerts (id, name, metric, threshold, operator, enabled, d
 VALUES ('alert-003', 'VPS RAM above 85%', 'mem_used_percent', 85, 'gt', 1, 120);
 ```
 
-Alerts are loaded at BigBase startup. Restart with `systemctl restart bigbase` after inserting.
+Alerts are loaded at your application startup. Restart with `systemctl restart your-app` after inserting.
 
 ## Base64 encoding workaround
 

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

@@ -122,5 +122,5 @@ After writing the bug file, print a one-line summary of the root cause and sugge
 
 <!-- story: e35s10 -->
 
-- [Feathers' Seams & Characterization Tests](https://github.com/danielvm-git/bigpowers/blob/main/docs/references/feathers.md) — seam types, characterization tests, and the legacy code change algorithm
-- [Fowler's Code Smells](https://github.com/danielvm-git/bigpowers/blob/main/docs/references/fowler.md) — identifying structural problems by smell before investigating
+- [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/orchestrate-project.md

@@ -93,7 +93,7 @@ Detailed documentation for the `orchestrate-project` meta-skill.
 ### PHASE 3: PLAN
 - **Goal**: Write a verifiable implementation plan with success criteria.
 - **Deliverables**: `release-plan.yaml`, `epics/eNN-*.yaml` with `verify:` per task.
-- **Skills**: `scope-work`, `slice-tasks`, `define-success`, `plan-work`.
+- **Skills**: `scope-work`, `slice-tasks`, `plan-work`.
 - **Gate**: Quality (request-review ≥94%) + slopcheck [SUS]/[SLOP].
 
 ### PHASE 4: BUILD

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

@@ -80,7 +80,7 @@ After writing `specs/REFACTOR_LATEST.md`, suggest running `kickoff-branch` next
 
 <!-- story: e35s10 -->
 
-- [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
+- [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/plan-release.md

@@ -16,7 +16,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](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-<slug>.md` | Story spec in [countable-story-format.md](../../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`) |
 
@@ -101,7 +101,7 @@ stories:
 ```
 ### 6. Save story specs (countable-story-format .md)
 
-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.
+Each story becomes a standalone `.md` file following [countable-story-format.md](../../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/prompts/plan-work.md

@@ -11,7 +11,7 @@ description: "PLANNING SPINE STEP 3 of 3 — Plan the work: write detailed imple
 
 Produce a detailed, verifiable implementation plan in the **active epic capsule directory** (`specs/epics/eNN-slug/`). Output: a story spec `.md` file (countable-story-format) and a decoupled `eNNsYY-tasks.yaml` with runnable verify commands. "I think it works" is not a step.
 
-> **HARD GATE** — Do NOT proceed with a plan until the task's success criteria are clear. If success is ambiguous, run `define-success` first to convert the task into "step → verify: <cmd>" pairs.
+> **HARD GATE** — Do NOT proceed with a plan until the task's success criteria are clear. If success is ambiguous, convert the task into "step → verify: `<cmd>`" pairs here before writing tasks — every task ships a runnable `verify:` or the plan is not done.
 >
 > **RECURSIVE DISCIPLINE** — This lifecycle applies to EVERY task, including updating these skills. Never skip planning because a task is "meta" or "just documentation."
 

package/.pi/prompts/using-bigpowers.md

@@ -7,7 +7,7 @@ description: "One-time bootstrap that introduces the bigpowers skills system, th
 > **HARD GATE** — **HARD GATE** — This skill is the entry point. Do NOT skip it when onboarding new users or starting a new session. It establishes the bigpowers methodology, lifecycle phases, and conventions.
 
 
-Welcome to **bigpowers** — a lifecycle of **70** agent skills for production-ready, TDD-driven software by solo developers.
+Welcome to **bigpowers** — a lifecycle of agent skills for production-ready, TDD-driven software by solo developers. The live catalog and its count are generated in [`SKILL-INDEX.md`](../../SKILL-INDEX.md); never hardcode the number here.
 
 ## Install
 
@@ -36,7 +36,7 @@ DISCOVER    survey-context → research-first → elaborate-spec
               ↓
 DESIGN      model-domain / define-language / grill-me / deepen-architecture / design-interface
               ↓
-PLAN        scope-work → slice-tasks → define-success → plan-work / plan-refactor
+PLAN        scope-work → slice-tasks → plan-work / plan-refactor
               ↓
 INITIATE    kickoff-branch → guard-git / hook-commits / seed-conventions
               ↓

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

@@ -257,7 +257,7 @@ jobs:
 
 ---
 
-## Reference block 2 — deploy.yml (BigBase, excerpt)
+## Reference block 2 — deploy.yml (generic web app, excerpt)
 
 ```yaml
 name: Deploy
@@ -275,7 +275,7 @@ concurrency:
   cancel-in-progress: false
 
 env:
-  SITE_URL: "https://CHANGE-ME.bigbase.click"
+  SITE_URL: "https://CHANGE-ME.example.com"
 
 jobs:
   deploy:
@@ -291,18 +291,15 @@ jobs:
           github-token: ${{ secrets.GITHUB_TOKEN }}
           run-id: ${{ github.event.workflow_run.id }}
           path: deploy-meta
-      # BigBase-specific composite action, not a bigpowers default: this deploy
-      # example targets the author's own hosting stack. Replace it with your
-      # platform's deploy step (or drop the deploy job entirely for CLI and
-      # library repos). bigpowers itself ships no deploy templates. (GH #104)
-      - uses: danielvm-git/.github/actions/bigbase-deploy@9c56ac10c629f3baa110ddb19136579e3c90d690  # v1
-        with:
-          site_id: ${{ secrets.BIGBASE_SITE_ID }}
-          app_type: go
-          site_url: ${{ env.SITE_URL }}
-          deploy_token: ${{ secrets.BIGBASE_DEPLOY_TOKEN }}
-          ref: ${{ steps.meta.outputs.ref }}
-          skip_health_check: true
+      # Placeholder deploy step — bigpowers ships no deploy templates and pins
+      # no third-party action. Substitute your platform's own step here, or drop
+      # the deploy job entirely for CLI and library repos. Pin whatever action
+      # you choose to a full commit SHA rather than a tag. (GH #104)
+      - name: Deploy
+        run: |
+          echo "Replace this step with your platform's deploy command."
+          echo "commit=$(jq -r .sha deploy-meta/deploy-meta.json)"
+          exit 1
       - name: Health check
         run: |
           curl -sf "${{ env.SITE_URL }}" || exit 1

package/.pi/skills/craft-skill/SKILL.md

@@ -44,7 +44,7 @@ Skill-body instructional prose MUST follow [AGENTIC-STE.md](../../../docs/AGENTI
    - Any reference materials to include?
    - What specs/ output does it produce (if any)?
 
-2. **Verify Principles** — Ensure the skill aligns with [PRINCIPLES.md](https://github.com/danielvm-git/bigpowers/blob/main/docs/PRINCIPLES.md):
+2. **Verify Principles** — Ensure the skill aligns with [PRINCIPLES.md](../../../docs/PRINCIPLES.md):
    - Is it atomic (verb-noun)?
    - Is it "deep" (simple interface, complex internal logic)?
    - Does it include Hard Gates?
@@ -58,7 +58,7 @@ Skill-body instructional prose MUST follow [AGENTIC-STE.md](../../../docs/AGENTI
    **Auto-skill from library README:** When user provides a library README or API docs URL, extract triggers and HARD GATEs.
    Draft verify commands and specs/ output into SKILL.md. Do NOT invent APIs not in the source.
 
-4. Add `model:` frontmatter (`haiku` | `sonnet` | `opus`) per [model-profiles.md](https://github.com/danielvm-git/bigpowers/blob/main/docs/references/model-profiles.md).
+4. Add `model:` frontmatter (`haiku` | `sonnet` | `opus`) per [model-profiles.md](../../../docs/references/model-profiles.md).
 
 > **STREAM CONTINUITY** — When writing file content, output in continuous chunks of ~200 lines. Do not pause. Continue immediately until complete. If you need time, emit a placeholder comment rather than going silent.
 

package/.pi/skills/define-success/SKILL.md

@@ -1,65 +1,12 @@
 ---
 name: define-success
-model: sonnet
-description: "Convert an imperative task statement into explicit \"step → verify: <cmd>\" pairs before implementation begins. Use before plan-work when success criteria are unclear, when a task lacks verifiable checkpoints, or when user says \"how will we know this is done?\"."
+model: haiku
+description: "TOMBSTONE — renamed/merged to plan-work. This stub resolves for one release then is removed."
 ---
 
-# Define Success
+# define-success (tombstoned)
 
-Transform "do X" into "step → verify: <cmd>" pairs. This is the pre-flight check before `plan-work` or `develop-tdd` — it makes success observable and removes ambiguity about when you're done.
+This skill has been renamed or merged into `plan-work`. Use `plan-work` instead.
 
-> **HARD GATE** — Success criteria must be testable and user-observable. "Code should be fast" is not testable. "Pageload latency < 2s" is testable.
-
-## Why this matters
-
-"Implement user authentication" is not a plan. It has no checkpoints, no evidence requirement, and no way to know if you're done. The Karpathy principle: every step must be independently verifiable with a runnable command. If you can't verify it, you can't prove it works.
-
-## Process
-
-### 1. Read the task statement
-
-Take the task as stated (from conversation, or from `specs/epics/ (see slice-tasks)`, or from `specs/product/SCOPE_LATEST.yaml`).
-
-### 2. Break into observable outcomes
-
-For each thing the task requires, identify:
-- The smallest unit of observable behavior that proves something works
-- The command that proves it
-
-Work at the level of behaviors (what the system does) not implementation steps (how you'll write the code).
-
-### 3. Write the pairs
-
-Format each pair as:
-```
-N. [What must be true] → verify: <runnable command>
-```
-
-Examples:
-
-```
-Task: "Add user registration to the API"
-
-1. POST /users accepts {email, name} and returns {id, email, name} → verify: curl -s -X POST http://localhost:3000/users -H 'Content-Type: application/json' -d '{"email":"test@test.com","name":"Test"}' | jq .id
-2. Duplicate email is rejected with 409 → verify: npm test -- user-registration.test.ts
-3. Missing email is rejected with 400 and descriptive error → verify: npm test -- user-validation.test.ts
-4. Password is hashed (never stored in plaintext) → verify: npm test -- user-security.test.ts
-5. All existing tests still pass → verify: npm test
-```
-
-### 4. Challenge completeness
-
-Ask yourself:
-- Is there any behavior the task requires that isn't covered by a verify step?
-- Is every verify step runnable right now without additional setup?
-- Does the final step verify the whole thing end-to-end?
-
-Add any missing pairs.
-
-### 5. Output
-
-Present the pairs to the user and ask: "Does this capture everything the task requires? Anything missing?"
-
-Once confirmed, these pairs become the skeleton for `plan-work`'s steps. Pass them along when calling `plan-work`.
-
-## Verify
+This stub exists for one release as a transition aid, then is removed once
+`scripts/validate-tombstones.sh` flags it as expired.

package/.pi/skills/deploy/SKILL.md

@@ -72,7 +72,7 @@ Platform-agnostic — supports multiple deployment targets via environment varia
 |----------|---------|---------|
 | Vercel | `VERCEL_TOKEN`, `VERCEL_PROJECT_ID` | `vercel deploy --prod --token $VERCEL_TOKEN` |
 | Netlify | `NETLIFY_AUTH_TOKEN`, `NETLIFY_SITE_ID` | `netlify deploy --prod --auth $NETLIFY_AUTH_TOKEN --dir $ARTIFACT_DIR` |
-| BigBase MCP | MCP tool call | `mcp deploy` via BigBase server |
+| Platform MCP | MCP tool call | `mcp deploy` via your platform MCP server |
 | rsync/SSH | `DEPLOY_SSH_USER`, `DEPLOY_SSH_HOST`, `DEPLOY_SSH_PATH` | `rsync -avz $ARTIFACT_DIR/ $DEPLOY_SSH_USER@$DEPLOY_SSH_HOST:$DEPLOY_SSH_PATH` |
 | Custom | `DEPLOY_COMMAND` | Run any deploy command string |
 

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

@@ -63,7 +63,7 @@ Once the user has answered the main questions, probe for assumptions:
 
 ### 4. Synthesize and confirm
 
-Summarize your understanding in 3–5 bullet points aligned with [countable-story-format.md](https://github.com/danielvm-git/bigpowers/blob/main/docs/countable-story-format.md):
+Summarize your understanding in 3–5 bullet points aligned with [countable-story-format.md](../../../docs/countable-story-format.md):
 - The problem (feeds into §1 Business narrative)
 - The solution and main flow (feeds into §5)
 - The key constraints and alternative flows (feeds into §6)