bigpowers 2.87.7 → 2.88.0

package/.windsurf/rules/release-branch.md

@@ -8,6 +8,7 @@ description: "Make the merge/PR/keep/discard decision for a feature branch, veri
 <!-- story: e45s15 -->
 <!-- story: e45s32 -->
 <!-- story: e45s39 -->
+<!-- story: e82s02 -->
 <!-- story: e20s02 -->
 
 
@@ -30,7 +31,7 @@ Read `specs/state.yaml` key `workflow_mode` (`team-pr` | `solo-git`). Fall back
 | **solo-local** | `workflow_mode: solo-git` | Auto: `scripts/land-branch.sh` if present, else fallback (Step 5) |
 | **team-pr** | `workflow_mode: team-pr` (default) | `gh pr create` → `gh pr merge --squash` |
 
-If unsure, prefer **solo-local**.
+If unsure, prefer **solo-local**. Also read `state.yaml` `vcs.kind`: Git follows the procedures below; Jujutsu uses workspaces/bookmarks and must not call Git-only landing scripts.
 
 ## Process
 
@@ -73,16 +74,21 @@ Run `gate-trace` before merge. FAIL blocks merge; CONCERNS requires explicit ove
 
 Options: **Release (solo-local)** / **Open PR** / **Keep branch** / **Discard**
 
-### 5. Solo-local integrate
+### 5. Integrate
 
-Run `commit-message` for the squash subject, then land:
+Run `commit-message` first. Git solo-local uses `land-branch.sh`. Jujutsu team mode explicitly advances and pushes a bookmark; `-m` is mandatory for commit/describe operations:
 
 ```bash
-# Path A (preferred):
+# Git solo-local
 bash scripts/land-branch.sh <task-slug> "feat(scope): description"
-# Path B (fallback if land-branch.sh missing): see REFERENCE.md
+# Jujutsu team PR
+jj describe -m "feat(scope): description"
+jj bookmark set <task-slug> -r @
+jj git push -b <task-slug>
 ```
 
+Jujutsu solo-local landing is unsupported: run `bp_require_vcs_operation "$PWD" land-branch` and stop with its remediation instead of invoking the Git backend.
+
 ### 6. Create PR (team-pr only)
 
 Create the pull request with a **literal provenance marker** in the body so agent-generated PRs are identifiable and do not rot silently:
@@ -131,7 +137,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).
+Git: prune worktree, delete branch, return to main. Jujutsu: `jj workspace forget <workspace>` only after integration; do not delete its bookmark implicitly. Cycle-time: see [REFERENCE.md](REFERENCE.md#cycle-time).
 
 Report: "Branch released."
 

package/.windsurf/rules/survey-context.md

@@ -4,6 +4,8 @@ model: haiku
 description: "Per-task context bootstrap — reads existing specs/ and tech-architecture docs to map the current lifecycle phase and suggest the next skill. Use at the start of any task, when returning after a break, or when unsure what to do next. For deriving a tech-stack doc from scratch, use map-codebase first."
 ---
 
+# story: e82s02
+
 # Survey Context
 
 Read the project's current state and give a phase map + next-skill recommendation. This is the "where am I?" skill — run it at the start of every task.
@@ -51,15 +53,18 @@ Legacy markdown (`specs/archive/STATE.md`, `RELEASE-PLAN.md`) is **not** SoT if
 
 If `CLAUDE.md` exists at the project root, read it for project context (stack, commands, architecture, conventions).
 
-### 4. Check git state
+### 4. Check VCS state
+
+Read `state.yaml` `vcs.kind` (or resolve `auto`). Use native identity:
 
 ```bash
-git status --short
-git log --oneline -5
-git branch --show-current
+# Git
+git status --short; git log --oneline -5; git branch --show-current
+# Jujutsu
+jj status; jj log -r 'mine() & ::@' -n 5
 ```
 
-Note: is there a feature branch active? Are there uncommitted changes? Do they match `specs/state.yaml` `git` block?
+For Jujutsu, compare stable change IDs and bookmarks with the `vcs` block; never interpret colocated Git's detached HEAD as branch state.
 
 ### 5. Map the lifecycle phase
 
@@ -124,7 +129,7 @@ Loop through all `specs/epics/*/epic.yaml` files and print a summary of story co
 
 ### check-gates (absorbed)
 
-Print the current `active_flow` from `specs/state.yaml`, run `bash scripts/validate-specs-yaml.sh` to verify YAML integrity, and show `git status` to report uncommitted changes and branch state. Use before handoffs or context transitions.
+Print `active_flow`, validate YAML, then show `git status` or `jj status` according to `vcs.kind`. Use before handoffs or context transitions.
 
 ## Handoff
 

package/.zcode/skills/commit-message/SKILL.md

@@ -4,6 +4,8 @@ model: haiku
 description: "Reviews working-tree changes, then drafts a Conventional Commits title/body and states the semantic-release version bump a single such commit would imply. Also notes which defensive-code categories were touched. Use when the user wants to commit recent work, prepare a Conventional Commits message, or asks for semantic-release / semver-consistent messaging before git commit."
 ---
 
+# story: e82s02
+
 # Commit Message
 > **HARD GATE** — **HARD GATE** — Commits must follow Conventional Commits spec (type(scope): description). Do NOT use vague messages like 'fix' or 'updates.' The message must explain the 'why,' not the 'what.'
 
@@ -15,7 +17,7 @@ description: "Reviews working-tree changes, then drafts a Conventional Commits t
 
 ## What "last chat" means
 
-- **Primary source of truth:** `git status`, `git diff` (unstaged), and `git diff --cached` (staged). Run these in the repo root (or the paths the user changed).
+- **Primary source of truth:** Read `state.yaml` `vcs.kind`. Git uses `git status`, `git diff`, and `git diff --cached`; Jujutsu uses `jj status`, `jj diff`, and `jj log -r @`. Run in the repo root.
 - **Context:** use the current conversation to summarize *intent* and to spot **breaking** API/behavior changes that diff alone may not show.
 - If the user tracks a session baseline (e.g. branch, tag, or `git stash create` at start), you may `git diff <baseline>..HEAD` plus uncommitted diffs; otherwise use only the index and working tree.
 
@@ -30,7 +32,7 @@ description: "Reviews working-tree changes, then drafts a Conventional Commits t
 7. **Deliver** — Output:
    - Proposed **full commit message** (title + optional body + footers).
    - **Release bump** this commit would drive: `patch` | `minor` | `major` | `none`.
-   - Optional `git add …` and `git commit -m` instructions; do **not** run destructive git commands unless the user asked.
+   - Optional native command: Git `git commit -m`; Jujutsu `jj commit -m`. Never omit `-m` or run destructive commands unless asked.
 
 ## Checklist before finalizing
 

package/.zcode/skills/kickoff-branch/SKILL.md

@@ -1,20 +1,21 @@
 ---
 name: kickoff-branch
 model: haiku
-description: "Create a git worktree and feature branch, then verify a clean test baseline before any code is written. Use when starting a new feature or task, when user wants to work in isolation from main, or mentions \"start a branch\" or \"new worktree\"."
+description: "Create an isolated Git worktree/branch or Jujutsu workspace, then verify a clean test baseline before code. Use when starting a feature or task."
 ---
 
 # story: e51s03
 # story: e20s03
+# story: e82s02
 
 
 # Kickoff Branch
 
-> **HARD GATE** — Direct work on `main` or `master` is PROHIBITED. Every task MUST start with this skill to create a feature branch or worktree.
+> **HARD GATE** — Direct Git work on `main`/`master` or reuse of an unrelated Jujutsu change is prohibited. Create a feature branch/worktree or Jujutsu workspace/change.
 >
 > **HARD GATE** — Do NOT proceed with development until **Preflight** passes on the default branch. Red Preflight blocks branch creation and all forward work — invoke `quick-fix` or `fix-bug` per CONVENTIONS § Discovered Defects.
 
-Create an isolated working environment before touching any code. **Preflight must be green** before you write feature code — solo-default owns the whole tree, not just the current task diff.
+Create an isolated Git worktree or Jujutsu workspace before code. **Preflight must be green** first — solo-default owns the whole tree.
 
 ## Process
 
@@ -22,9 +23,13 @@ Create an isolated working environment before touching any code. **Preflight mus
 
 Ask if not already known: "What's the name of this feature or task?" Use it as the branch name slug (kebab-case, max 40 chars).
 
-### 2. Anchor on default branch (main or master)
+### 2. Select the VCS procedure
 
-> **HARD GATE** — Kickoff MUST start from an updated, clean default branch in the **primary** repository root (not a linked worktree).
+Read `state.yaml` `vcs.kind`. For `jj`, do not run the Git blocks below: verify with `jj status` and `jj log -r '::@' -n 5`, create isolation with `jj workspace add ../<task-slug> -r @`, then run `jj -R ../<task-slug> describe -m "feat: <task>"`. Record the new stable change ID. For `git`, continue below.
+
+### 2a. Anchor Git on the default branch (main or master)
+
+> **HARD GATE** — Git kickoff MUST start from an updated, clean default branch in the **primary** repository root (not a linked worktree).
 
 ```bash
 # Detect default branch
@@ -63,7 +68,7 @@ fi
 - **Non-spec dirty files** (src/, scripts/, SKILL.md, …) still enforce the full clean-tree gate.
 - If not on `$DEFAULT` after checkout, stop and fix before continuing.
 
-### 3. Pre-flight & Conflict Resolution
+### 3. Git pre-flight & conflict resolution
 
 Before creating the worktree, verify the target environment is clean:
 
@@ -83,7 +88,7 @@ git worktree list | grep "<task-slug>"
 - **Branch exists:** If the branch exists but no worktree is attached, ask to use the existing branch (`git worktree add ../<task-slug> <task-slug>`) or delete it.
 - **Ghost worktree:** If `git worktree list` shows the path but the directory is missing, run `git worktree prune` to clear the stale metadata. `bash scripts/cleanup-worktrees.sh` does this plus reports any worktree whose branch is already merged or deleted — advisory only, it prints the `git worktree remove`/`git branch -d` commands rather than running them, so review before acting.
 
-### 4. Create worktree + branch
+### 4. Create Git worktree + branch
 
 ```bash
 # From the main repo root (not another worktree)

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

@@ -8,6 +8,7 @@ description: "Make the merge/PR/keep/discard decision for a feature branch, veri
 <!-- story: e45s15 -->
 <!-- story: e45s32 -->
 <!-- story: e45s39 -->
+<!-- story: e82s02 -->
 <!-- story: e20s02 -->
 
 
@@ -30,7 +31,7 @@ Read `specs/state.yaml` key `workflow_mode` (`team-pr` | `solo-git`). Fall back
 | **solo-local** | `workflow_mode: solo-git` | Auto: `scripts/land-branch.sh` if present, else fallback (Step 5) |
 | **team-pr** | `workflow_mode: team-pr` (default) | `gh pr create` → `gh pr merge --squash` |
 
-If unsure, prefer **solo-local**.
+If unsure, prefer **solo-local**. Also read `state.yaml` `vcs.kind`: Git follows the procedures below; Jujutsu uses workspaces/bookmarks and must not call Git-only landing scripts.
 
 ## Process
 
@@ -73,16 +74,21 @@ Run `gate-trace` before merge. FAIL blocks merge; CONCERNS requires explicit ove
 
 Options: **Release (solo-local)** / **Open PR** / **Keep branch** / **Discard**
 
-### 5. Solo-local integrate
+### 5. Integrate
 
-Run `commit-message` for the squash subject, then land:
+Run `commit-message` first. Git solo-local uses `land-branch.sh`. Jujutsu team mode explicitly advances and pushes a bookmark; `-m` is mandatory for commit/describe operations:
 
 ```bash
-# Path A (preferred):
+# Git solo-local
 bash scripts/land-branch.sh <task-slug> "feat(scope): description"
-# Path B (fallback if land-branch.sh missing): see REFERENCE.md
+# Jujutsu team PR
+jj describe -m "feat(scope): description"
+jj bookmark set <task-slug> -r @
+jj git push -b <task-slug>
 ```
 
+Jujutsu solo-local landing is unsupported: run `bp_require_vcs_operation "$PWD" land-branch` and stop with its remediation instead of invoking the Git backend.
+
 ### 6. Create PR (team-pr only)
 
 Create the pull request with a **literal provenance marker** in the body so agent-generated PRs are identifiable and do not rot silently:
@@ -131,7 +137,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).
+Git: prune worktree, delete branch, return to main. Jujutsu: `jj workspace forget <workspace>` only after integration; do not delete its bookmark implicitly. Cycle-time: see [REFERENCE.md](REFERENCE.md#cycle-time).
 
 Report: "Branch released."
 

package/.zcode/skills/survey-context/SKILL.md

@@ -4,6 +4,8 @@ model: haiku
 description: "Per-task context bootstrap — reads existing specs/ and tech-architecture docs to map the current lifecycle phase and suggest the next skill. Use at the start of any task, when returning after a break, or when unsure what to do next. For deriving a tech-stack doc from scratch, use map-codebase first."
 ---
 
+# story: e82s02
+
 # Survey Context
 
 Read the project's current state and give a phase map + next-skill recommendation. This is the "where am I?" skill — run it at the start of every task.
@@ -51,15 +53,18 @@ Legacy markdown (`specs/archive/STATE.md`, `RELEASE-PLAN.md`) is **not** SoT if
 
 If `CLAUDE.md` exists at the project root, read it for project context (stack, commands, architecture, conventions).
 
-### 4. Check git state
+### 4. Check VCS state
+
+Read `state.yaml` `vcs.kind` (or resolve `auto`). Use native identity:
 
 ```bash
-git status --short
-git log --oneline -5
-git branch --show-current
+# Git
+git status --short; git log --oneline -5; git branch --show-current
+# Jujutsu
+jj status; jj log -r 'mine() & ::@' -n 5
 ```
 
-Note: is there a feature branch active? Are there uncommitted changes? Do they match `specs/state.yaml` `git` block?
+For Jujutsu, compare stable change IDs and bookmarks with the `vcs` block; never interpret colocated Git's detached HEAD as branch state.
 
 ### 5. Map the lifecycle phase
 
@@ -124,7 +129,7 @@ Loop through all `specs/epics/*/epic.yaml` files and print a summary of story co
 
 ### check-gates (absorbed)
 
-Print the current `active_flow` from `specs/state.yaml`, run `bash scripts/validate-specs-yaml.sh` to verify YAML integrity, and show `git status` to report uncommitted changes and branch state. Use before handoffs or context transitions.
+Print `active_flow`, validate YAML, then show `git status` or `jj status` according to `vcs.kind`. Use before handoffs or context transitions.
 
 ## Handoff
 

package/CHANGELOG.md

@@ -1,3 +1,17 @@
+# [2.88.0](https://github.com/danielvm-git/bigpowers/compare/v2.87.8...v2.88.0) (2026-09-01)
+
+
+### Features
+
+* **e82:** upstream fork innovations — Jujutsu VCS, OMP plugin, community credit ([#118](https://github.com/danielvm-git/bigpowers/issues/118)) ([274894f](https://github.com/danielvm-git/bigpowers/commit/274894fe794fc4db380ba4d011e05ef5b8cbd3d0))
+
+## [2.87.8](https://github.com/danielvm-git/bigpowers/compare/v2.87.7...v2.87.8) (2026-09-01)
+
+
+### Bug Fixes
+
+* **cli:** bigpowers init provisions scripts/ + specs/ into consumer projects ([#117](https://github.com/danielvm-git/bigpowers/issues/117)) ([37bc0bf](https://github.com/danielvm-git/bigpowers/commit/37bc0bf72875cd66898d35138870982c8af2d310)), closes [#116](https://github.com/danielvm-git/bigpowers/issues/116) [#116](https://github.com/danielvm-git/bigpowers/issues/116) [#114](https://github.com/danielvm-git/bigpowers/issues/114) [#116](https://github.com/danielvm-git/bigpowers/issues/116) [#114](https://github.com/danielvm-git/bigpowers/issues/114)
+
 ## [2.87.7](https://github.com/danielvm-git/bigpowers/compare/v2.87.6...v2.87.7) (2026-09-01)
 
 

package/CONTRIBUTORS.md

@@ -0,0 +1,48 @@
+# story: e82s04
+# Contributors
+
+This file records external contributors whose work has been adapted or
+upstreamed into bigpowers. Code authored inside this repository is committed
+directly by [@danielvm-git](https://github.com/danielvm-git).
+
+---
+
+## Community Contributors
+
+### Kevin Oberlies — [favilo/bigpowers](https://github.com/favilo/bigpowers)
+
+**Contribution: Jujutsu VCS support + configurable project-runtime library (e82s01, e82s02)**
+
+Kevin built and maintained a fork that introduced two cohesive capabilities:
+
+1. **`scripts/lib/project-runtime.sh`** — a configurable project-settings library
+   (`bp_specs_path`, `bp_vcs_kind`) that reads from `.bigpowers/config.yaml` or
+   environment variables, with auto-detection of Jujutsu repos via `.jj/`.
+   Enables bigpowers to operate in consumer projects with non-standard specs
+   directories or VCS backends.
+
+2. **Jujutsu-aware lifecycle skills** — updated `commit-message`, `kickoff-branch`,
+   `release-branch`, and `survey-context` to read `state.yaml` `vcs.kind` and
+   branch on native `jj` commands vs. Git, including `jj workspace add` for
+   isolation, `jj bookmark set` for releases, and colocated-repo detection.
+
+Discovered via fork audit on 2026-09-01.
+
+---
+
+### XcluEzy7 — [XcluEzy7/bigpowers](https://github.com/XcluEzy7/bigpowers)
+
+**Contribution: OMP plugin extension (e82s03)**
+
+XcluEzy7 built a native [oh-my-pi](https://github.com/oh-my-pi) OMP plugin that:
+
+- Discovers every skill in `skills/` at runtime and registers each as a slash command.
+- Exposes a unified `bigpowers_skill` LLM tool with `list`/`get`/`run` operations.
+- Ports bigpowers' git-safety pre-tool-use hook into OMP's `tool_call` event API,
+  blocking dangerous patterns and enforcing Conventional Commits.
+
+The upstream port (in `extensions/omp-hooks.ts`) rebases the discovery logic onto
+the current `skills/<name>/SKILL.md` source layout. The model-frontmatter stripping
+and foreign AGENTS.md content from the original branch were not carried over.
+
+Discovered via fork audit on 2026-09-01.

package/README.md

@@ -216,6 +216,25 @@ pi install .
 pi install npm:bigpowers
 ```
 
+### Provision a consumer project (`bigpowers init`)
+
+pi's package contract registers **skills and prompts only** — it has no resource
+type for arbitrary project files, and no lifecycle script runs on install. Skills
+reference the package's `scripts/*.sh` tooling project-relative (e.g.
+`bash scripts/run-skill-verify.sh`, verify gates like `test -f scripts/... &&
+test -d specs/bugs`), so after installing the package, run **one command per
+consumer project** to provision what the skills expect:
+
+```bash
+cd <your-project>
+npx bigpowers init        # or: bigpowers init
+```
+
+This symlinks `<project>/scripts` → the installed package's `scripts/` tree and
+scaffolds `specs/bugs/` + `specs/verifications/`. It refuses (never clobbers) a
+`scripts/` you already own; `bigpowers init --remove` undoes it. The same step
+applies to `npm i -g bigpowers` / `npx bigpowers setup` consumers.
+
 **What you get:**
 - **pi skills** in `.pi/skills/` (one per SKILL.md) — loaded automatically into pi's system prompt as `<available_skills>`
 - **pi prompt templates** in `.pi/prompts/` — slash commands like `/survey-context`, `/plan-work`
@@ -366,6 +385,14 @@ This project is a synthesis of decades of software engineering thought. It would
 - **Jarek Wasowski** for identifying Spec-Driven Development (SDD) as the missing link for AI agents.
 - **AkitaOnRails** for adapting classical clean code principles to the reality of the AI token economy.
 
+### Community Contributors
+
+bigpowers has been shaped by contributors who extended it in their own forks.
+See [CONTRIBUTORS.md](CONTRIBUTORS.md) for the full list.
+
+- **[Kevin Oberlies (favilo)](https://github.com/favilo/bigpowers)** — Jujutsu VCS support across lifecycle skills + `project-runtime.sh` configurable settings library.
+- **[XcluEzy7](https://github.com/XcluEzy7/bigpowers)** — OMP plugin extension (`extensions/omp-hooks.ts`): native skill discovery, slash commands, and git-safety hooks for the oh-my-pi runtime.
+
 ---
 
 ## 📄 License

package/SKILL-INDEX.md

@@ -59,7 +59,7 @@
 | 31 | Build | `extract-design` | "Extract a Google DESIGN.md file from an HTML prototype (claude.ai/design or any | ✅ Active |
 | 32 | Build | `guard-git` | Block dangerous git commands (push, force push, reset --hard, clean, branch -D,  | ✅ Active |
 | 33 | Build | `hook-commits` | Set up pre-commit hooks with lint-staged (Prettier), type checking, and tests in | ✅ Active |
-| 34 | Build | `kickoff-branch` | Create a git worktree and feature branch, then verify a clean test baseline befo | ✅ Active |
+| 34 | Build | `kickoff-branch` | Create an isolated Git worktree/branch or Jujutsu workspace, then verify a clean | ✅ Active |
 | 35 | Build | `orchestrate-project` | Meta-skill that enforces the 6-phase core loop (discover → elaborate → plan  | ✅ Active |
 | 36 | Build | `publish-package` | "Package registry publishing for npm, crates.io, PyPI, and Homebrew. Verifies pr | ✅ Active |
 | 37 | Build | `quick-fix` | "Streamlined fast-path for trivial data-only fixes — no TDD, no branching cere | ✅ Active |

package/bin/bigpowers.js

@@ -75,6 +75,13 @@ if (cmd === 'setup' || cmd === 'install') {
   return;
 }
 
+if (cmd === 'init') {
+  // Provision the CURRENT project (cwd): scripts/ link + specs/ scaffolding (#116)
+  const initScript = path.join(ROOT, 'bin', 'init.js');
+  require(initScript);
+  return;
+}
+
 if (cmd === 'update') {
   // Pull the newest release first (global installs), then re-sync + refresh symlinks.
   selfUpdateGlobalPackage();
@@ -106,6 +113,7 @@ bigpowers — agent skills for spec-driven, test-first development
 
 Commands:
   bigpowers setup    Install skills into ~/.claude/skills/
+  bigpowers init     Provision the CURRENT project: scripts/ link + specs/ scaffolding (run per project)
   bigpowers update   Fetch the latest release (global installs) + re-sync and refresh symlinks
   bigpowers status   Show installed version and skill count (warns if a newer release exists)
   bigpowers help     This message

package/bin/init.js

@@ -0,0 +1,39 @@
+#!/usr/bin/env node
+// bigpowers init — provision the CURRENT project (cwd) for skill tooling.
+// story: BUG-2026-08-31-pi-scripts-provisioning (#116)
+//
+// Package installs (pi install npm:bigpowers, npm i -g, npx) register skills
+// but never provision a project-local scripts/ tree — pi's package contract
+// has no resource type for project files and no lifecycle script runs — so
+// SKILL.md commands (`bash scripts/*.sh`) and `→ verify:` gates fail in every
+// consumer project. `bigpowers init` (or `npx bigpowers init`) links the
+// package's scripts/ into the project and scaffolds specs/{bugs,verifications}.
+
+'use strict';
+
+const path = require('path');
+
+const ROOT = path.dirname(path.dirname(__filename));
+const { initProject, initProjectRemove } = require('../scripts/lib/install-helpers.js');
+
+if (process.argv.includes('--remove')) {
+  initProjectRemove(ROOT);
+  console.log('bigpowers init --remove: removed the managed scripts/ link');
+  console.log('  (and specs/ scaffolding dirs only where untouched).');
+  process.exit(0);
+}
+
+try {
+  const result = initProject(ROOT);
+  if (result.skipped === 'cwd-is-package') {
+    console.log('bigpowers init: already inside the bigpowers package — nothing to provision.');
+  } else {
+    console.log('bigpowers init: linked scripts/ → package scripts tree.');
+    console.log('bigpowers init: ensured specs/bugs/ + specs/verifications/ scaffolding.');
+    console.log('Skill commands and verify gates (fix-bug, verify-work, wire-ci, …) now resolve here.');
+  }
+} catch (e) {
+  // e.g. Refusing to replace a user-owned scripts/ — surface it, don't stack-trace.
+  console.error(`bigpowers init: ${e.message}`);
+  process.exit(1);
+}