bigpowers 2.84.0 → 2.85.0

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

@@ -9,12 +9,12 @@ description: "CI pipeline setup with pre-built templates and local validation. G
 >
 > **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.
+Generate, validate, and test CI workflows. Detects your project type, copies org templates from `danielvm-git/.github/workflow-templates/`, 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)
+1. **Test Build Release workflow** — `.github/workflows/test-build-release.yml` with lint → test → build → release (single pipeline, `needs:` chain)
+2. **Deploy workflow** — `.github/workflows/deploy.yml` triggered via `workflow_run` (BigBase/Pages stacks only; CLI/library repos omit this)
 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
@@ -23,45 +23,41 @@ Generate, validate, and test CI workflows. Detects your project type, produces p
 
 ### 1. Detect project type
 
-Read the project root for manifest files to determine which template to use:
+Read the project root for manifest files to determine which template pair to copy:
 
-| 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 |
+| Manifest | Type | Template pair (from `.github` repo) |
+|----------|------|-------------------------------------|
+| `Cargo.toml` | Rust | `test-build-release-monorepo.yml` + `deploy-monorepo.yml` (or monorepo subset) |
+| `package.json` | Node | `test-build-release-node.yml` + `deploy-node.yml` |
+| `setup.py` / `pyproject.toml` | Python | `test-build-release-python.yml` + `deploy-python.yml` |
+| `go.mod` | Go | `test-build-release-go.yml` + `deploy-go.yml` |
+| Static site (no server) | Static | `test-build-release-static.yml` + `deploy-static.yml` |
+| `Package.swift` | Swift | `test-build-release-swift.yml` only (no deploy yet) |
+| Multiple detected | Polyglot | `test-build-release-monorepo.yml` + `deploy-monorepo.yml` |
 
-If no manifest is found, prompt the user to specify the type or pass `--type <rust|node|python|go|cpp>`.
+**CLI/library repos** (no hosted target): copy only `test-build-release-<stack>.yml` → `test-build-release.yml`. The `release` job is terminal; skip `deploy.yml`. See `docs/how-to/migrate-ci-cd/migration-plan.md` § CLI and library repos.
 
-### 2. Generate CI workflow
+If no manifest is found, prompt the user to specify the type or pass `--type <rust|node|python|go|static|swift>`.
 
-Create `.github/workflows/ci.yaml` with standard steps derived from the project type and its manifest:
+### 2. Copy test-build-release template
 
-**Rust template (`Cargo.toml`):**
-See [REFERENCE.md](REFERENCE.md)
-
-**Node template (`package.json`):**
-See [REFERENCE.md](REFERENCE.md)
+Copy the matching template from `~/Developer/.github/workflow-templates/` to `.github/workflows/test-build-release.yml`. **Do not rename the workflow `name:` field** — deploy listens for `"Test Build Release"`.
 
-**Python template (`setup.py` / `pyproject.toml`):**
-See [REFERENCE.md](REFERENCE.md)
+Edit placeholders: `APP_TYPE`, `SITE_URL`, language versions.
 
-**Go template (`go.mod`):**
-See [REFERENCE.md](REFERENCE.md)
+See [REFERENCE.md](REFERENCE.md) for stack-specific job shapes.
 
-**C/C++ template (`CMakeLists.txt`):**
-See [REFERENCE.md](REFERENCE.md)
+### 3. Copy deploy template (hosted stacks only)
 
-### 3. Generate release workflow (if semantic-release detected)
+If the project deploys to BigBase or GitHub Pages:
 
-If the project has semantic-release configured (in `package.json`, `.releaserc`, or `release.config.js`), also generate `.github/workflows/release.yaml`:
+```bash
+cp ~/Developer/.github/workflow-templates/deploy-${STACK}.yml .github/workflows/deploy.yml
+```
 
-See [REFERENCE.md](REFERENCE.md)
+Configure `BIGBASE_SITE_ID`, `BIGBASE_DEPLOY_TOKEN`, and matching `SITE_URL`. Deploy runs via `workflow_run` after TBR succeeds on `main` with `cancel-in-progress: false`.
 
-> **NPM_TOKEN is required** for publishing to npm. Without it, semantic-release will fail at the publish step. See `--validate` to check this.
+Skip this step for CLI/library repos.
 
 ### 4. Validate workflows (`--validate`)
 
@@ -96,6 +92,8 @@ Add the following to the project's documentation or CLAUDE.md after setup:
 | `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 |
+| Deploy never runs | TBR workflow renamed | Keep `name: Test Build Release` in test-build-release.yml |
+| Release rebuilds binary | Artifact not downloaded | `release` job must `download-artifact` from `build` |
 
 ## Verify
 
@@ -119,26 +117,24 @@ Add the following to the project's documentation or CLAUDE.md after setup:
 
 ## Examples
 
-### Create CI for a Rust project
+### Create CI for a Go project (TBR + optional deploy)
 
 ```bash
-# Detect from Cargo.toml, generate workflows
-wire-ci
+# Copy org templates
+cp ~/Developer/.github/workflow-templates/test-build-release-go.yml .github/workflows/test-build-release.yml
+cp ~/Developer/.github/workflow-templates/deploy-go.yml .github/workflows/deploy.yml
 
-# Validate generated workflows
 wire-ci --validate
-
-# Run locally with act
 wire-ci --dry-run
 ```
 
-### Create CI for a Node project with semantic-release
+### Create CI for a CLI tool (TBR only, no deploy)
 
 ```bash
-wire-ci
+cp ~/Developer/.github/workflow-templates/test-build-release-go.yml .github/workflows/test-build-release.yml
+# Edit release job to download build artifact — see big-release dogfood
+
 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)
@@ -147,7 +143,6 @@ wire-ci --validate
 wire-ci --validate --check-only
 ```
 
-
 ---
 
 ## Options
@@ -159,8 +154,7 @@ wire-ci --validate --check-only
 | `--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 |
-
+| `--no-deploy` | Skip deploy.yml even for hosted stacks |
 
 ---
 
@@ -173,202 +167,191 @@ When `wire-ci` is used as part of `build-epic`:
 
 ---
 
-## Reference block 1
+## Reference block 1 — test-build-release.yml (Go, excerpt)
 
 ```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
-```
+name: Test Build Release
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
 
----
+permissions:
+  contents: read
 
-## Reference block 2
+concurrency:
+  group: pipeline-${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
 
-```yaml
-name: CI
-on: [push, pull_request]
 jobs:
-  test:
-    runs-on: ubuntu-latest
+  lint:
+    runs-on: ubuntu-22.04
+    timeout-minutes: 10
     steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-node@v4
+      - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0  # v7.0.0
+      - uses: actions/setup-go@924ae3a1cded613372ab5595356fb5720e22ba16  # v6.5.0
         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
+          go-version: '1.22'
+          cache: true
+      - uses: golangci/golangci-lint-action@55c2c1448f86e01eaae002a5a3a9624417608d84  # v6.5.2
+        with:
+          version: v1.64.8
 
-```yaml
-name: CI
-on: [push, pull_request]
-jobs:
   test:
-    runs-on: ubuntu-latest
+    needs: [lint]
+    runs-on: ubuntu-22.04
     steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-python@v5
+      - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0  # v7.0.0
+      - uses: actions/setup-go@924ae3a1cded613372ab5595356fb5720e22ba16  # v6.5.0
         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
+          go-version: '1.22'
+          cache: true
+      - run: go vet ./...
+      - run: go test ./... -count=1
 
-```yaml
-name: CI
-on: [push, pull_request]
-jobs:
-  test:
-    runs-on: ubuntu-latest
+  build:
+    needs: [test]
+    runs-on: ubuntu-22.04
     steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-go@v5
+      - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0  # v7.0.0
+      - uses: actions/setup-go@924ae3a1cded613372ab5595356fb5720e22ba16  # v6.5.0
         with:
-          go-version: stable
+          go-version: '1.22'
           cache: true
-      - run: go vet ./...
-      - run: go test ./...
       - run: go build ./...
+      - run: jq -n --arg sha "${{ github.sha }}" '{sha: $sha}' > deploy-meta.json
+      - uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a  # v7.0.1
+        with:
+          name: deploy-meta
+          path: deploy-meta.json
+
+  release:
+    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
+    needs: [build]
+    permissions:
+      contents: write
+    steps:
+      - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0  # v7.0.0
+        with:
+          fetch-depth: 0
+      - run: npx semantic-release
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 ```
 
 ---
 
-## Reference block 5
+## Reference block 2 — deploy.yml (BigBase, excerpt)
 
 ```yaml
-name: CI
-on: [push, pull_request]
+name: Deploy
+on:
+  workflow_run:
+    workflows: ["Test Build Release"]
+    types: [completed]
+
+permissions:
+  contents: read
+  actions: read
+
+concurrency:
+  group: deploy-production
+  cancel-in-progress: false
+
+env:
+  SITE_URL: "https://CHANGE-ME.bigbase.click"
+
 jobs:
-  test:
-    runs-on: ubuntu-latest
+  deploy:
+    if: >
+      github.event.workflow_run.conclusion == 'success' &&
+      github.event.workflow_run.head_branch == 'main'
+    runs-on: ubuntu-22.04
+    environment: production
     steps:
-      - uses: actions/checkout@v4
-      - run: cmake -B build
-      - run: cmake --build build
-      - run: ctest --test-dir build
+      - uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c  # v8.0.1
+        with:
+          name: deploy-meta
+          github-token: ${{ secrets.GITHUB_TOKEN }}
+          run-id: ${{ github.event.workflow_run.id }}
+          path: deploy-meta
+      - 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
+      - name: Health check
+        run: |
+          curl -sf "${{ env.SITE_URL }}" || exit 1
 ```
 
 ---
 
-## Reference block 6
+## Reference block 3 — CLI dogfood (big-release pattern)
 
 ```yaml
-name: Release
-on:
-  push:
-    branches: [main]
-jobs:
-  release:
-    runs-on: ubuntu-latest
-    permissions:
-      contents: write
-      issues: write
-      pull-requests: write
-      id-token: write
+  build:
+    needs: [test]
     steps:
-      - uses: actions/checkout@v4
+      - run: make build
+      - uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a  # v7.0.1
         with:
-          fetch-depth: 0
-      - uses: actions/setup-node@v4
+          name: big-release-${{ github.sha }}
+          path: bin/big-release
+
+  release:
+    needs: [build]
+    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
+    steps:
+      - uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c  # v8.0.1
         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 }}
+          name: big-release-${{ github.sha }}
+          path: bin
+      - run: make release   # cross-compile assets only; host binary from artifact
+      - run: big-release release --verbose
 ```
 
+No `deploy.yml` — CLI publishes via the release job.
+
 ---
 
-## Reference block 7
+## Reference block 4 — validate script
 
 ```bash
-# Validate YAML syntax
-for f in .github/workflows/*.yaml; do
+for f in .github/workflows/*.yml .github/workflows/*.yaml; do
+  [ -f "$f" ] || continue
   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
+for f in .github/workflows/test-build-release.yml; 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
+    echo "WARNING: $f missing permissions block"
   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"
+if grep -q 'workflows: \["Test Build Release"\]' .github/workflows/deploy.yml 2>/dev/null; then
+  if ! grep -q 'name: Test Build Release' .github/workflows/test-build-release.yml; then
+    echo "WARNING: deploy.yml listens for Test Build Release but TBR name may differ"
   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
+fi
 ```
 
 ---
 
-## Reference block 8
+## Reference block 5 — dry-run
 
 ```bash
-# Option A: Use act (recommended)
 if command -v act &>/dev/null; then
-  act push --dry-run
-  echo "OK: act dry-run completed"
+  act push --dry-run -W .github/workflows/test-build-release.yml
 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"
+  gh workflow run test-build-release.yml --ref "$(git branch --show-current)"
 else
-  echo "NOTE: Install act (https://github.com/nektos/act) for full local dry-run"
-  echo "      Install gh CLI for remote dry-run"
+  echo "Install act or gh for dry-run"
 fi
 ```

package/.pi/skills/audit-code/SKILL.md

@@ -95,6 +95,10 @@ bash scripts/lib/parallel-review-worktrees.sh audit-code
 - [ ] Dependency Inversion: dependencies injected, not imported globally where avoidable
 - [ ] **Chapter 17 Heuristics**: Code is free of smells documented in `audit-code/HEURISTICS.md` (G, N, C, T)
 
+### Refactoring Smells (Fowler)
+
+Explicitly name any detected smells: Mysterious Name, Duplicated Code, Feature Envy, Data Clumps, Primitive Obsession, Message Chains, Middle Man.
+
 ### Code Style (CONVENTIONS.md)
 
 - [ ] Functions: 4–20 lines; split if longer
@@ -106,13 +110,6 @@ bash scripts/lib/parallel-review-worktrees.sh audit-code
 - [ ] Conditionals: expressed as positives (G29)
 - [ ] Comments explain WHY, not WHAT
 
-### Agent Readability (Akita's Lens)
-
-- [ ] Functions are small enough to fit in a standard context window (4–20 lines)
-- [ ] Names are unique and specific enough to be `grep`-able (grep returns < 5 hits)
-- [ ] Types are explicit (no `any`, no inferred return types for public APIs)
-- [ ] Code avoids deep nesting (max 2 levels) and uses early returns
-
 ### Red Flags
 
 Before reporting, name any rationalization you caught yourself making for skipping a checklist item. Silence is not acceptable — if you skipped an item, state the reason explicitly.

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

@@ -6,7 +6,7 @@ description: "Create new bigpowers skills with proper structure, progressive dis
 
 # Craft Skill
 
-> **HARD GATE** — Do NOT name a skill without a two-word verb-noun pair. Do NOT merge a new skill without running `sync-skills.sh` — the generated `.cursor/rules/` and `.gemini/` artifacts must match the source SKILL.md.
+> **HARD GATE** — Do NOT name a skill without a two-word verb-noun pair. Do NOT merge a new skill without running `sync-skills.sh`. Generated `.cursor/rules/` and `.gemini/` artifacts MUST match the source SKILL.md.
 
 ## CSO Description Discipline (e45s02)
 
@@ -21,11 +21,25 @@ The YAML `description` is the **Catalog Selection Object** — the only field ag
 
 Move process detail into the SKILL.md body or REFERENCE.md — never into `description`.
 
+## Agentic STE body discipline (e79s02)
+
+Skill-body instructional prose MUST follow [AGENTIC-STE.md](../../../docs/AGENTIC-STE.md).
+
+| Rule | Limit |
+|------|-------|
+| Sentence length | ≤20 words per instruction sentence |
+| Voice | Imperative, active |
+| Directive terms | MUST, MUST NOT, NEVER, ALWAYS, DO, DO NOT |
+| Banned modals | should, might, could, may, consider, try, generally, typically |
+| Scope | SKILL.md body only — not YAML `description`, not `terse-mode` output |
+
+> **HARD GATE** — Do NOT merge a new or edited skill until `bash scripts/validate-agentic-ste.sh --strict skills/<name>/SKILL.md` exits 0. Fix violations before `sync-skills.sh`.
+
 ## Process
 
 1. **Gather requirements** — ask user about:
    - What task/domain does the skill cover?
-   - What specific use cases should it handle?
+   - Which use cases must the skill handle?
    - Does it need executable scripts or just instructions?
    - Any reference materials to include?
    - What specs/ output does it produce (if any)?
@@ -41,7 +55,8 @@ Move process detail into the SKILL.md body or REFERENCE.md — never into `descr
    - Additional reference files if content exceeds 100 lines
    - Utility scripts if deterministic operations needed
 
-   **Auto-skill from library README:** When user provides a library README or API docs URL, extract: triggers, HARD GATEs, verify commands, specs/ output — draft SKILL.md without inventing APIs not in the source.
+   **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).
 
@@ -50,10 +65,11 @@ Move process detail into the SKILL.md body or REFERENCE.md — never into `descr
 5. **Review with user** — present draft and ask:
    - Does this cover your use cases?
    - Anything missing or unclear?
-   - Should any section be more/less detailed?
+   - Does any section need more or less detail?
 
 6. **Completion-honesty gate (HARD GATE — e45s02)** — Before declaring done:
    - Run `bash scripts/validate-skill-description.sh skills/<name>/SKILL.md` — must exit 0
+   - Run `bash scripts/validate-agentic-ste.sh --strict skills/<name>/SKILL.md` — must exit 0 (e79s02)
    - Run `bash scripts/sync-skills.sh` — must complete without error
    - Run `bash scripts/run-skill-verify.sh <name>` if the skill defines a verify command
    - Show terminal output for each — narration without evidence is rejected
@@ -78,6 +94,7 @@ After drafting, verify:
 - [ ] Consistent terminology with CONVENTIONS.md
 - [ ] specs/ output documented if applicable
 - [ ] `validate-skill-description.sh` exits 0
+- [ ] `validate-agentic-ste.sh --strict` exits 0 (e79s02)
 - [ ] `sync-skills.sh` run to propagate to Cursor/Gemini
 - [ ] `bash scripts/validate-skill-catalog.sh` passes for the new skill (HARD GATE — completion honesty)
 

package/.pi/skills/grill-me/SKILL.md

@@ -18,6 +18,14 @@ Interview relentlessly about every aspect of this plan until reaching shared und
 
 If a question can be answered by exploring the codebase, explore it instead.
 
+### Facts vs. Decisions Boundary
+
+Distinguish between **facts** and **decisions**:
+- **Facts** — things discoverable by exploring the codebase, reading docs, or checking APIs. Do not ask the user to confirm facts; find them yourself.
+- **Decisions** — choices that require user input (trade-offs, preferences, priorities). Always present options and ask the user to choose.
+
+Never "grill yourself" — if the answer is in the code, go find it. Only ask questions where the user's judgment is needed.
+
 ## Docs mode
 
 Ground every challenge in real documentation — no assumption about a library's behavior goes unchecked. See [REFERENCE.md](../../../skills/grill-me/REFERENCE.md) for the full process.
@@ -29,6 +37,10 @@ Short form:
 4. Report confirmed ✓, corrected ✗ (with the real behavior), and uncertain → `spike-prototype`.
 5. Update the plan for each confirmed discrepancy.
 
+## Confirmation Gate
+
+> **HARD GATE** — Do NOT enact the plan or generate specifications until the user explicitly confirms shared understanding. Wait for explicit approval (e.g., "looks good", "confirmed", "proceed") before transitioning to any implementation, spec-writing, or task-slicing step.
+
 ---
 
 # Docs Mode — Full Process

package/.pi/skills/grill-with-docs/SKILL.md

@@ -23,6 +23,18 @@ description: "Doc-grounded variant of grill-me — stress-tests plan assumptions
 - If docs contradict the plan, plan loses until updated.
 - Prefer official docs over blog posts.
 
+## Facts vs. Decisions Boundary
+
+Distinguish between **facts** and **decisions**:
+- **Facts** — things discoverable by reading docs, checking APIs, or exploring the codebase. Do not ask the user to confirm facts; find them yourself.
+- **Decisions** — choices that require user input (trade-offs, preferences, priorities). Always present options and ask the user to choose.
+
+Never "grill yourself" — if the answer is in the docs, go fetch it. Only ask questions where the user's judgment is needed.
+
+## Confirmation Gate
+
+> **HARD GATE** — Do NOT enact the plan or generate specifications until the user explicitly confirms shared understanding. Wait for explicit approval (e.g., "looks good", "confirmed", "proceed") before transitioning to any implementation, spec-writing, or task-slicing step.
+
 ## Verify
 
 → verify: `grep -c 'https\?://' skills/grill-with-docs/SKILL.md | awk '{if($1>=2) print "OK"; else print "NEEDS DOCS"}'`

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

@@ -86,6 +86,7 @@ Review for:
 4. Design — are there simpler or more robust approaches?
 5. Edge cases — what inputs or states could cause failures?
 6. Security — any injection, auth, or data exposure risks?
+7. Refactoring smells — explicitly name any detected Fowler smells: Mysterious Name, Duplicated Code, Feature Envy, Data Clumps, Primitive Obsession, Message Chains, Middle Man
 
 For each finding, categorize as: must-fix / should-fix / consider.
 Run the verify command and report the result.