bigpowers 2.82.4 → 2.83.1

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

@@ -0,0 +1,375 @@
+---
+name: wire-ci
+model: sonnet
+description: "CI pipeline setup with pre-built templates and local validation. Generates GitHub Actions workflows, validates YAML syntax and permissions, supports dry-run via act/gh. The CI equivalent of wire-observability."
+---
+
+# Wire CI
+
+> **HARD GATE** — Do not ship a project without CI. Run this skill before first merge to main or when adding CI to an existing project.
+>
+> **HARD GATE** — CI that is untestable locally will break every cycle. Always run `--validate` after generating workflows and `--dry-run` before pushing.
+
+Generate, validate, and test CI workflows. Detects your project type, produces platform-appropriate GitHub Actions configurations, and provides local verification to catch auth, permissions, and syntax issues before they reach CI.
+
+## What this sets up
+
+1. **CI workflow** — `.github/workflows/ci.yaml` with test, lint, typecheck, build steps
+2. **Release workflow** — `.github/workflows/release.yaml` with semantic-release (if applicable)
+3. **`--validate` mode** — checks YAML syntax, workflow permissions, required secrets, and common pitfalls
+4. **`--dry-run` mode** — runs workflows locally via `act` or `gh workflow run` to prove correctness before push
+5. **Failure pattern documentation** — common CI failure categories and their fixes
+
+## Process
+
+### 1. Detect project type
+
+Read the project root for manifest files to determine which template to use:
+
+| Manifest | Type | Template |
+|----------|------|----------|
+| `Cargo.toml` | Rust | Rust CI: test, clippy, fmt, build |
+| `package.json` | Node | Node CI: test, lint, typecheck, build |
+| `setup.py` / `pyproject.toml` | Python | Python CI: pytest, ruff/mypy/flake8, build |
+| `go.mod` | Go | Go CI: test, vet, staticcheck, build |
+| `CMakeLists.txt` | C/C++ | C/C++ CI: cmake build, ctest |
+| Multiple detected | Polyglot | Combined workflows or error if ambiguous |
+
+If no manifest is found, prompt the user to specify the type or pass `--type <rust|node|python|go|cpp>`.
+
+### 2. Generate CI workflow
+
+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)
+
+**Node template (`package.json`):**
+See [REFERENCE.md](REFERENCE.md)
+
+**Python template (`setup.py` / `pyproject.toml`):**
+See [REFERENCE.md](REFERENCE.md)
+
+**Go template (`go.mod`):**
+See [REFERENCE.md](REFERENCE.md)
+
+**C/C++ template (`CMakeLists.txt`):**
+See [REFERENCE.md](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)
+
+> **NPM_TOKEN is required** for publishing to npm. Without it, semantic-release will fail at the publish step. See `--validate` to check this.
+
+### 4. Validate workflows (`--validate`)
+
+Run `wire-ci --validate` to check all generated workflow files:
+
+See [REFERENCE.md](REFERENCE.md)
+
+**Exit codes:**
+- `0` — all checks pass (no errors)
+- `1` — YAML syntax errors found
+- `2` — validation warnings only (missing permissions, secrets, etc.)
+
+### 5. Dry-run workflows (`--dry-run`)
+
+Attempt to run the generated workflows locally to catch errors before push:
+
+See [REFERENCE.md](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.
+
+### 6. Document common CI failure patterns
+
+Add the following to the project's documentation or CLAUDE.md after setup:
+
+| Failure | Cause | Fix |
+|---------|-------|-----|
+| `npm publish` fails | `NPM_TOKEN` not set as repo secret | Add `NPM_TOKEN` to GitHub repo secrets |
+| `semantic-release` fails on push | Missing `permissions: contents: write` | Add `permissions: contents: write` to release job |
+| `cargo publish` auth fail | `CARGO_REGISTRY_TOKEN` not set | Add token to `~/.cargo/config.toml` or env |
+| `go vet` fails | Go version mismatch | Match `go.mod` `go` directive with setup-go version |
+| `cargo clippy` errors | New lints in Rust nightly | `cargo clippy --fix` or allow specific lints |
+| `act` not found | Docker not running or act not installed | `brew install act` / `docker ps` to verify Docker |
+| Hardcoded Node version stale | `.nvmrc` exists but workflow uses hardcoded version | Use `node-version-file: .nvmrc` instead |
+
+## Verify
+
+→ verify: `grep -ci "template\|workflow\|validate\|dry.run" skills/wire-ci/SKILL.md | awk '{if($1>=3) print "OK: semantics"; else print "FAIL: missing"}'`
+→ verify: `grep -q "wire-ci" SKILL-INDEX.md && echo "OK: in SKILL-INDEX" || echo "FAIL: not indexed"`
+
+---
+
+# Wire Ci — Reference
+
+## Navigation
+
+| Lines | Section |
+|-------|---------|
+| 1 | Title |
+| 3–14 | Navigation |
+| 16–38 | Examples |
+| 40–52 | Options |
+| 54–62 | Integration with build-epic |
+| 64–270 | Reference blocks 1–8 |
+
+## Examples
+
+### Create CI for a Rust project
+
+```bash
+# Detect from Cargo.toml, generate workflows
+wire-ci
+
+# Validate generated workflows
+wire-ci --validate
+
+# Run locally with act
+wire-ci --dry-run
+```
+
+### Create CI for a Node project with semantic-release
+
+```bash
+wire-ci
+wire-ci --validate
+# Expect warning: "npm publish step found but no NPM_TOKEN in secrets"
+# Fix: add NPM_TOKEN to repo secrets
+```
+
+### Validate existing workflows (no generation)
+
+```bash
+wire-ci --validate --check-only
+```
+
+
+---
+
+## Options
+
+| Flag | Description |
+|------|-------------|
+| `--validate` | Check YAML syntax, permissions, secrets, common pitfalls |
+| `--dry-run` | Run workflows locally via `act` or dispatch via `gh` |
+| `--check-only` | Only validate, do not generate new files |
+| `--type <type>` | Force project type (skip auto-detection) |
+| `--force` | Overwrite existing workflow files |
+| `--no-release` | Skip release workflow generation even if semantic-release detected |
+
+
+---
+
+## Integration with build-epic
+
+When `wire-ci` is used as part of `build-epic`:
+
+1. **During develop-tdd**: If the task modifies `.github/workflows/`, run `wire-ci --validate` as a CI dry-run sub-step
+2. **During release-branch**: After push, run `gh run list --limit 1 --branch main --json status,conclusion` to verify CI passes
+
+---
+
+## Reference block 1
+
+```yaml
+name: CI
+on: [push, pull_request]
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions-rust/toolchain@v1
+        with:
+          toolchain: stable
+          components: clippy, rustfmt
+      - run: cargo fmt --all -- --check
+      - run: cargo clippy -- -D warnings
+      - run: cargo test
+      - run: cargo build --release
+```
+
+---
+
+## Reference block 2
+
+```yaml
+name: CI
+on: [push, pull_request]
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 20
+          cache: npm
+      - run: npm ci
+      - run: npm test
+      - run: npm run lint 2>/dev/null || true
+      - run: npm run typecheck 2>/dev/null || true
+      - run: npm run build 2>/dev/null || true
+```
+
+---
+
+## Reference block 3
+
+```yaml
+name: CI
+on: [push, pull_request]
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.12"
+          cache: pip
+      - run: pip install -e ".[dev]" || pip install -e .
+      - run: pip install pytest ruff mypy
+      - run: ruff check .
+      - run: mypy . 2>/dev/null || true
+      - run: pytest
+```
+
+---
+
+## Reference block 4
+
+```yaml
+name: CI
+on: [push, pull_request]
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-go@v5
+        with:
+          go-version: stable
+          cache: true
+      - run: go vet ./...
+      - run: go test ./...
+      - run: go build ./...
+```
+
+---
+
+## Reference block 5
+
+```yaml
+name: CI
+on: [push, pull_request]
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - run: cmake -B build
+      - run: cmake --build build
+      - run: ctest --test-dir build
+```
+
+---
+
+## Reference block 6
+
+```yaml
+name: Release
+on:
+  push:
+    branches: [main]
+jobs:
+  release:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: write
+      issues: write
+      pull-requests: write
+      id-token: write
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 20
+          cache: npm
+      - run: npm ci
+      - run: npm run build 2>/dev/null || true
+      - run: npx semantic-release
+        env:
+          GITHUB_TOKEN: \${{ secrets.GITHUB_TOKEN }}
+          NPM_TOKEN: \${{ secrets.NPM_TOKEN }}
+```
+
+---
+
+## Reference block 7
+
+```bash
+# Validate YAML syntax
+for f in .github/workflows/*.yaml; do
+  python3 -c "import yaml; yaml.safe_load(open('$f'))" || echo "FAIL: $f has YAML syntax errors"
+done
+
+# Check permissions block presence
+for f in .github/workflows/*.yaml; do
+  if grep -q "permissions:" "$f"; then
+    echo "OK: $f has permissions block"
+  else
+    echo "WARNING: $f missing permissions block — add one for security"
+  fi
+done
+
+# Check for npm publish without NPM_TOKEN
+for f in .github/workflows/*.yaml; do
+  if grep -q "npm publish\|npx semantic-release" "$f"; then
+    if ! grep -q "NPM_TOKEN" "$f"; then
+      echo "WARNING: $f has npm publish/semantic-release but no NPM_TOKEN secret"
+    fi
+  fi
+done
+
+# Check for hardcoded Node versions
+for f in .github/workflows/*.yaml; do
+  if grep -q "node-version: [0-9]" "$f" && grep -qv "node-version-file\|\.nvmrc" "$f"; then
+    echo "NOTE: $f has hardcoded Node version — consider using .nvmrc instead"
+  fi
+done
+
+# Check for common secrets reference errors
+for f in .github/workflows/*.yaml; do
+  # Secrets referencing something that doesn't exist in the workflow
+  grep -oP 'secrets\.\w+' "$f" | sort -u | while read -r secret; do
+    echo "REF: $f references $secret"
+  done
+done
+```
+
+---
+
+## Reference block 8
+
+```bash
+# Option A: Use act (recommended)
+if command -v act &>/dev/null; then
+  act push --dry-run
+  echo "OK: act dry-run completed"
+elif command -v gh &>/dev/null; then
+  # Option B: Use gh workflow run (remote test, no local docker)
+  gh workflow run ci.yaml --ref "$(git branch --show-current)"
+  echo "OK: CI workflow dispatched. Check status: gh run list"
+else
+  echo "NOTE: Install act (https://github.com/nektos/act) for full local dry-run"
+  echo "      Install gh CLI for remote dry-run"
+fi
+```

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

@@ -0,0 +1,97 @@
+---
+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."
+---
+
+# 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.