bigpowers 2.87.4 → 2.87.6

package/.gemini/extensions/bigpowers/skills/wire-observability/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: wire-observability
+model: sonnet
+description: "Add structured JSON logging, observability commands, and idempotent setup scripts to a project. Use when a project needs production-readiness instrumentation, when user wants structured logging, or as a production-readiness gate at any phase of development."
+disable-model-invocation: true
+---
+
+# Wire Observability
+> **HARD GATE** — **HARD GATE** — Observability is not optional. Before shipping, verify: structured logging is in place, key metrics are instrumented, error cases emit signals. 'We'll add metrics later' becomes 'never.'
+
+
+Add structured logging, observability commands, and idempotent setup scripts. Can be invoked at any phase — recommended at the end of the first working slice, before the first deploy.
+
+## What this sets up
+
+1. **Structured JSON logging** — machine-readable logs for debugging and observability
+2. **Observability commands** — how to check the system's health documented in CLAUDE.md
+3. **Idempotent setup scripts** — scripts that can be run repeatedly without side effects
+
+## Process
+
+### 1. Assess current state
+
+Check what's already in place:
+- Is there a logging library? (pino, winston, structlog, zap, slog, etc.)
+- Is logging JSON or plain text?
+- Is there a health check endpoint or command?
+- Are there setup scripts? Are they idempotent?
+
+### 2. Add structured JSON logging
+
+**For user-facing CLI output:** plain text is fine.
+**For everything else:** structured JSON.
+
+Structured log entry format:
+```json
+{
+  "level": "info",
+  "timestamp": "2025-01-15T10:23:45.123Z",
+  "message": "User created",
+  "userId": "usr_abc123",
+  "requestId": "req_xyz789"
+}
+```
+
+Guidelines:
+- Include `level`, `timestamp`, `message` in every entry
+- Add context fields relevant to the operation (userId, requestId, traceId)
+- Log at boundaries: HTTP requests in/out, DB queries, external API calls, background job start/end
+- Log errors with stack traces: `logger.error({ err, context }, "Operation failed")`
+- **Never log secrets, passwords, tokens, or PII**
+
+### 3. Document observability commands in CLAUDE.md
+
+Add an "Observability" section to the project's CLAUDE.md:
+
+```markdown
+## Observability
+
+| What | Command |
+|------|---------|
+| View logs | `<log tail command>` |
+| Health check | `<health check command>` |
+| Check DB connection | `<db ping command>` |
+| View metrics | `<metrics command>` |
+```
+
+### 4. Write idempotent setup scripts
+
+An idempotent script can be run multiple times and always produces the same result (no errors on re-run).
+
+Pattern: check if the thing already exists before creating it.
+
+```bash
+#!/usr/bin/env bash
+set -euo pipefail
+
+# Idempotent: only create if not exists
+if ! psql -c "SELECT 1 FROM pg_database WHERE datname = 'myapp'" | grep -q 1; then
+  createdb myapp
+  echo "Database created"
+else
+  echo "Database already exists, skipping"
+fi
+```
+
+Place setup scripts in `scripts/setup.sh` (or language-appropriate equivalent). Document the command in CLAUDE.md under Commands.
+
+### 5. Verify
+
+- [ ] Run the app and confirm JSON logs appear in the correct format
+- [ ] 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/.gemini/extensions/bigpowers/skills/write-document/SKILL.md

@@ -0,0 +1,282 @@
+---
+name: write-document
+model: sonnet
+description: "Write, organize, and sync high-integrity technical documents using the BMAD methodology. Ensures every document is Bold, Minimal, Actionable, and Durable. Use when creating architectural docs, technical guides, or organizing the specs/ directory."
+disable-model-invocation: true
+---
+
+# Write Document (BMAD)
+
+Create high-signal technical documentation that serves as an expert collaborator for both humans and AI. This skill enforces the BMAD principles to prevent context rot and ensure architectural durability.
+
+**Distinct from `edit-document`:** Use this skill to create a document that does not yet exist. Use `edit-document` when a document already exists and needs restructuring, clarity, or prose improvements.
+
+> **HARD GATE** — Every document must have a clear "Reason for Existence." If a document doesn't provide actionable leverage for a caller or test, do not create it.
+
+## The BMAD Principles
+
+| Principle | Execution |
+| :--- | :--- |
+| **B**old | Make strong assertions. Define clear boundaries and "Never" rules. No "it might" or "usually." |
+| **M**inimal | High-density, low-filler. **Circuit Breaker**: If the file exceeds 300 lines or the session exceeds 20 turns, you MUST run `terse-mode` and compact state before saving. |
+| **A**ctionable | Link every doc to a verifiable outcome. **Architectural Docs**: Verify via Gherkin features (`specs/verifications/features/`) or grep-based structure checks (`grep -c "pattern" file`) that prove the design's *constraints* are present. |
+| **D**urable | Design for the long-term. **Scalability**: Use "Nested Indexing"—root files link to module-level `GEMINI.md` indexes; do not list individual sub-files in the root. |
+
+## Process
+
+### 1. Identify the Artifact Type & Scope
+
+Choose the correct BMAD-BigPowers artifact:
+- **Decision Record (ADR)**: For "Why" decisions (saved to `specs/adr/`).
+- **Context Map**: For system-wide architectural mapping (`specs/tech-architecture/tech-stack.md`).
+- **Technical Guide**: For "How-to" with verification (saved to `<module>/REFERENCE.md`).
+- **Behavioral Feature**: Gherkin-style compliance specs (saved to `specs/verifications/features/`).
+- **Project README**: Project-facing documentation (saved to `README.md` at project root).
+
+**Cross-Cutting Concerns**: If a doc affects multiple modules, place the authoritative source in the lowest common ancestor directory and use "Delegates" (one-line pointers) in sub-directories to maintain the Single Source of Truth without violating the Stepdown Rule.
+
+### 2. Draft with Semantic Velocity
+
+> **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.
+
+Write the document focusing on "Expert Collaboration":
+- **Instructions over Descriptions**: Tell the reader (human or AI) exactly how to interact with the system.
+- **Provenance Links**: Link to ADRs, Issues, or Commits to preserve intent.
+- **The Stepdown Rule**: Information should descend exactly one level of abstraction. If a root doc needs to explain a leaf-level detail, it must point to a sub-index first.
+
+### 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.
+3. Fill gaps from `CLAUDE.md` / `AGENTS.md` commands if available (prefer `AGENTS.md`); use `TODO` markers otherwise.
+4. Output and suggest `edit-document` for polish.
+
+→ verify: `test -f README.md && [ "$(grep -c '^## ' README.md)" -ge 7 ]`
+
+### 3. Apply the 94% Quality Gate
+
+Before finalizing, audit the document against these red flags:
+- [ ] **Filler Language**: Are there pleasantries or "I hope this helps"? (Delete them).
+- [ ] **Ambiguity**: Are there "usually," "often," or "it depends" without specific conditions?
+- [ ] **Dead Ends**: Does the document end without a "Next Step" or "Verification" command?
+- [ ] **Shallow Content**: Does it restate the code without explaining the *intent* or *contracts*?
+
+### 4. Sync and Organize
+
+- **Big Powers Hierarchy**: Place the document in the correct tier (Global -> Project -> Sub-directory). Project READMEs are an exception — they go to project root (`README.md`), not `specs/`.
+- **Nested Indexing**: If adding a module-level doc, ensure the module's `GEMINI.md` is updated. If the module's index is new, add it to the root `GEMINI.md`.
+- **Sync**: Run `scripts/sync-skills.sh` if the document is a `SKILL.md` or affects generated artifacts.
+
+## Rules
+
+- **Minimalism is a requirement**: If a document can be a 5-line table, do not make it a 5-line essay.
+- **Verifiable outcomes**: Every technical document must include at least one `verify:` command. For architecture, this can be a `grep` or `run_shell_command` that validates the existence of required files or patterns.
+- **No speculative docs**: Do not write documentation for features that do not exist yet unless explicitly doing `elaborate-spec`.
+
+
+Suggest next skill: `audit-code` or `sync-skills.sh`.
+
+---
+
+# Project README Template
+
+Combined from dbader/readme-template and jehna/readme-best-practices. No TOC.
+
+## Navigation
+
+| Lines | Section |
+|-------|---------|
+| 1 | Title |
+| 5–40 | Navigation |
+| 41–42 | Sections |
+| 43–54 | 1. Title + Badges |
+| 55–60 | 2. Tagline |
+| 61–64 | 3. Description |
+| 65–67 | 4. Prerequisites |
+| 68–75 | Prerequisites |
+| 76–78 | 5. Installation |
+| 79–89 | Installation |
+| 90–92 | 6. Usage |
+| 93–102 | Usage |
+| 103–105 | 7. Features |
+| 106–113 | Features |
+| 114–116 | 8. Configuration |
+| 117–125 | Configuration |
+| 126–128 | 9. Development Setup |
+| 129–139 | Development |
+| 140–142 | 10. Running Tests |
+| 143–152 | Tests |
+| 153–155 | 11. Contributing |
+| 156–164 | Contributing |
+| 165–167 | 12. Changelog |
+| 168–172 | Changelog |
+| 173–175 | 13. Links |
+| 176–181 | Links |
+| 182–184 | 14. License |
+| 185–191 | License |
+| 192–194 | 15. Credits (optional) |
+| 195–199 | Credits |
+| 200–202 | Verify |
+
+## Sections
+
+### 1. Title + Badges
+
+```markdown
+# Project Name
+
+![License](https://img.shields.io/badge/License-MIT-yellow.svg)
+![npm version](https://img.shields.io/npm/v/your-package.svg)
+
+```
+
+Fill badges from CLAUDE.md stack info if available. Default to license + version badges.
+
+### 2. Tagline
+
+```markdown
+> One-line description of what this project does and why it matters.
+```
+
+### 3. Description
+
+2-3 paragraphs: what problem it solves, who it's for, and what makes it different.
+
+### 4. Prerequisites
+
+```markdown
+## Prerequisites
+
+- **Runtime**: Node.js v18+ (from CLAUDE.md)
+- **Package manager**: npm (or pnpm/yarn)
+```
+
+Auto-fill from CLAUDE.md commands section when possible.
+
+### 5. Installation
+
+```markdown
+## Installation
+
+```bash
+npm install -g your-package
+# or
+npx your-package
+```
+```
+
+Prefer npx one-shot if applicable; list global install as alternative.
+
+### 6. Usage
+
+```markdown
+## Usage
+
+```bash
+your-command --help
+your-command do-something
+```
+```
+
+Include the most common 1-2 commands. Link to full docs if they exist.
+
+### 7. Features
+
+```markdown
+## Features
+
+- Feature 1: short description
+- Feature 2: short description
+```
+
+3-6 bullet points of what the project does. Derived from the project's purpose.
+
+### 8. Configuration
+
+```markdown
+## Configuration
+
+| Variable | Default | Description |
+|----------|---------|-------------|
+| `VAR_NAME` | `value` | What it controls |
+```
+
+Use `TODO` markers if unknown.
+
+### 9. Development Setup
+
+```markdown
+## Development
+
+```bash
+git clone <repo-url>
+cd project
+npm install
+```
+```
+
+Auto-fill from CLAUDE.md `Run` and `Build` commands.
+
+### 10. Running Tests
+
+```markdown
+## Tests
+
+```bash
+npm test
+npm run lint
+```
+```
+
+Auto-fill from CLAUDE.md `Test` and `Lint` commands.
+
+### 11. Contributing
+
+```markdown
+## Contributing
+
+1. Fork the repo.
+2. Create a feature branch (`git checkout -b feature/my-thing`).
+3. Commit changes (`git commit -am 'Add my thing'`).
+4. Push (`git push origin feature/my-thing`).
+5. Open a Pull Request.
+```
+
+### 12. Changelog
+
+```markdown
+## Changelog
+
+See [CHANGELOG.md](../../CHANGELOG.md) or [Releases](https://github.com/user/repo/releases).
+```
+
+### 13. Links
+
+```markdown
+## Links
+
+- Repository: https://github.com/user/repo
+- Issue tracker: https://github.com/user/repo/issues
+```
+
+### 14. License
+
+```markdown
+## License
+
+MIT — see [LICENSE](../../LICENSE) for details.
+```
+
+Detect from CLAUDE.md or project LICENSE file.
+
+### 15. Credits (optional)
+
+```markdown
+## Credits
+
+Built with [bigpowers](https://www.npmjs.com/package/bigpowers).
+```
+
+## Verify
+
+After generation, run: `grep -c "^## " README.md` — expect ≥ 7 section headings.

package/.pi/package.json

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

package/CHANGELOG.md

@@ -1,3 +1,17 @@
+## [2.87.6](https://github.com/danielvm-git/bigpowers/compare/v2.87.5...v2.87.6) (2026-09-01)
+
+
+### Bug Fixes
+
+* **install:** refuse to replace non-managed files or dirs during setup ([#114](https://github.com/danielvm-git/bigpowers/issues/114)) ([f866adc](https://github.com/danielvm-git/bigpowers/commit/f866adca03901fc3a2797e968f866176cf604891)), closes [#112](https://github.com/danielvm-git/bigpowers/issues/112)
+
+## [2.87.5](https://github.com/danielvm-git/bigpowers/compare/v2.87.4...v2.87.5) (2026-08-07)
+
+
+### Bug Fixes
+
+* **packaging:** ship .gemini/.cursor in npm tarball — Gemini install works on global installs (BUG-2026-08-07) ([#111](https://github.com/danielvm-git/bigpowers/issues/111)) ([ae174aa](https://github.com/danielvm-git/bigpowers/commit/ae174aae75c0bc0aae4cf95570eb53cdd12670cb))
+
 ## [2.87.4](https://github.com/danielvm-git/bigpowers/compare/v2.87.3...v2.87.4) (2026-08-07)
 
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "bigpowers",
-  "version": "2.87.4",
+  "version": "2.87.6",
   "description": "73 agent skills synthesizing 17 years of software engineering discipline into a prescriptive methodology for solo developers",
   "main": "index.js",
   "scripts": {

package/scripts/lib/install-helpers.js

@@ -19,6 +19,31 @@
 const fs = require('fs');
 const path = require('path');
 
+// Package root — every link the installer creates points back into this
+// directory, which is how "managed" is detected (see assertReplaceable).
+const REPO_ROOT = path.resolve(__dirname, '..', '..');
+
+// Refuse to replace a destination that is not already a bigpowers-managed
+// symlink. Prevents setup from silently destroying a user's own file or
+// directory (e.g. an existing ~/.claude/hooks/rtk-rewrite.sh installed by
+// RTK itself, or a user-authored skills dir with a colliding name). (#112)
+function assertReplaceable(dst) {
+  let st;
+  try {
+    st = fs.lstatSync(dst);
+  } catch {
+    return; // nothing there — safe to create
+  }
+  if (st.isSymbolicLink()) {
+    const target = fs.readlinkSync(dst);
+    if (target.startsWith(REPO_ROOT)) return; // managed by bigpowers — safe to re-link
+  }
+  throw new Error(
+    `Refusing to replace ${dst}: it exists and is not a bigpowers-managed symlink. ` +
+    `Back it up or remove it manually, then re-run setup.`
+  );
+}
+
 function linkSkills(skillsDir, targetDir) {
   for (const entry of fs.readdirSync(skillsDir, { withFileTypes: true })) {
     if (!entry.isDirectory()) continue;
@@ -27,11 +52,8 @@ function linkSkills(skillsDir, targetDir) {
     const src = path.join(skillsDir, entry.name);
     const dst = path.join(targetDir, entry.name);
 
-    // Remove existing symlink or directory
-    try {
-      fs.rmSync(dst, { force: true, recursive: true });
-    } catch {}
-
+    assertReplaceable(dst);
+    fs.rmSync(dst, { force: true });
     fs.symlinkSync(src, dst);
   }
 }
@@ -42,18 +64,14 @@ function linkDir(src, dst) {
       `Link source missing: ${src} (run bash scripts/sync-skills.sh first)`
     );
   }
-  // Remove existing symlink or directory
-  try {
-    fs.rmSync(dst, { force: true, recursive: true });
-  } catch {}
+  assertReplaceable(dst);
+  fs.rmSync(dst, { force: true });
   fs.symlinkSync(src, dst);
 }
 
 function linkFile(src, dst) {
-  // Remove existing symlink or file
-  try {
-    fs.rmSync(dst, { force: true });
-  } catch {}
+  assertReplaceable(dst);
+  fs.rmSync(dst, { force: true });
   fs.symlinkSync(src, dst);
 }
 
@@ -82,10 +100,8 @@ function linkHook(src, dst) {
       `Hook source missing: ${src} (expected under repo skills/ or scripts/hooks/; fix path or restore file)`
     );
   }
-  // Remove existing symlink or file
-  try {
-    fs.rmSync(dst, { force: true });
-  } catch {}
+  assertReplaceable(dst);
+  fs.rmSync(dst, { force: true });
   fs.symlinkSync(src, dst);
   try { fs.chmodSync(src, 0o755); } catch {}
 }

package/scripts/test-install-helpers.js

@@ -213,6 +213,37 @@ try {
     'install surface must not reference bare guard-git/ path'
   );
 
+  // story: BUG-2026-08-07-gemini-hooks-missing-npm-package
+  // The npm tarball must ship every path the installer hard-links from the
+  // package root. .npmignore edits that strip installer-referenced paths are
+  // regressions (Gemini hooks "Hook source missing" on global npm installs).
+  {
+    const npmignore = fs
+      .readFileSync(path.join(ROOT, '.npmignore'), 'utf8')
+      .split(/\r?\n/)
+      .map((l) => l.trim())
+      .filter(Boolean);
+    const critical = [
+      '.gemini/extensions/bigpowers/hooks/session-start',
+      '.gemini/extensions/bigpowers/hooks/run-hook.cmd',
+      '.gemini/extensions/bigpowers/hooks/before-tool-git-guard.sh',
+      '.cursor/rules',
+      '.pi/skills',
+      'skills/audit-code/SKILL.md',
+    ];
+    const isIgnored = (p) =>
+      npmignore.some((pat) => {
+        const pp = pat.replace(/\/+$/, '');
+        return p === pp || p.startsWith(pp + '/') || p.split('/').includes(pp);
+      });
+    for (const p of critical) {
+      assert.ok(
+        !isIgnored(p),
+        `.npmignore must not exclude installer-referenced path: ${p} (BUG-2026-08-07)`
+      );
+    }
+  }
+
   console.log('test-install-helpers: ALL PASS');
 } finally {
   rmSync(tmpHome, { recursive: true, force: true });