bigpowers 1.0.0 → 1.1.0

package/hooks/pre-tool-use.sh

@@ -2,16 +2,16 @@
 # bigpowers — pre-tool-use.sh
 # Harness-agnostic Git Safety Hook for Claude Code, Cursor, and Gemini CLI.
 # Enforces:
-# 1. Block dangerous commands (push, reset --hard, etc.)
+# 1. Block dangerous commands (force push, reset --hard, etc.)
 # 2. Enforce Conventional Commits for 'git commit'
 # 3. Block direct commits/pushes to protected branches (main, master)
+#    unless GIT_BIGPOWERS_LAND=1 (scripts/land-branch.sh only)
 
 set -euo pipefail
 
 # Configuration
 PROTECTED_BRANCHES=("main" "master")
 DANGEROUS_PATTERNS=(
-  "git push"
   "git reset --hard"
   "git clean -fd"
   "git clean -f"
@@ -19,14 +19,26 @@ DANGEROUS_PATTERNS=(
   "git checkout \\."
   "git restore \\."
   "push --force"
+  "push -f"
   "reset --hard"
 )
 CONVENTIONAL_COMMITS_REGEX='^(feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert)(\(.+\))?!?:[[:space:]].+'
+LAND_MODE="${GIT_BIGPOWERS_LAND:-}"
 
 # Detect mode from environment (for Gemini/Claude/Cursor parity)
 # GIT_GUARDRAILS_MODE: claude (default) | cursor | gemini
 MODE="${GIT_GUARDRAILS_MODE:-claude}"
 
+deny() {
+  local reason="$1"
+  if [ "$MODE" = "gemini" ]; then
+    jq -nc --arg reason "$reason" '{decision: "deny", reason: $reason}'
+  else
+    echo "$reason" >&2
+    exit 2
+  fi
+}
+
 # Read input from stdin
 INPUT=$(cat)
 
@@ -38,17 +50,10 @@ if [ -z "$COMMAND" ]; then
   exit 0
 fi
 
-# 1. Check for dangerous patterns
+# 1. Check for dangerous patterns (git push is NOT blanket-blocked)
 for p in "${DANGEROUS_PATTERNS[@]}"; do
   if echo "$COMMAND" | grep -qE "$p"; then
-    REASON="BLOCKED: '$COMMAND' matches dangerous pattern '$p'. Use a safer approach or ask the user."
-    if [ "$MODE" = "gemini" ]; then
-      jq -nc --arg reason "$REASON" '{decision: "deny", reason: $reason}'
-    else
-      echo "$REASON" >&2
-      exit 2
-    fi
-    exit 0
+    deny "BLOCKED: '$COMMAND' matches dangerous pattern '$p'. Use a safer approach or ask the user."
   fi
 done
 
@@ -56,25 +61,36 @@ done
 if [[ "$COMMAND" =~ git[[:space:]]+commit ]] || [[ "$COMMAND" =~ git[[:space:]]+push ]]; then
   CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD 2>/dev/null || echo "unknown")
 
-  # Branch protection
+  # Push to protected branches
   if [[ "$COMMAND" =~ git[[:space:]]+push ]]; then
+    PUSH_TARGETS_PROTECTED=false
     for b in "${PROTECTED_BRANCHES[@]}"; do
-      if [[ "$COMMAND" =~ [[:space:]]+$b ]] || [[ "$CURRENT_BRANCH" == "$b" ]]; then
-        REASON="BLOCKED: Direct push to protected branch '$b' is forbidden. Use a feature branch and PR."
-        if [ "$MODE" = "gemini" ]; then
-          jq -nc --arg reason "$REASON" '{decision: "deny", reason: $reason}'
-        else
-          echo "$REASON" >&2
-          exit 2
-        fi
-        exit 0
+      if [[ "$COMMAND" =~ [[:space:]]+$b([[:space:]]|$) ]] \
+        || [[ "$COMMAND" =~ :$b([[:space:]]|$) ]] \
+        || [[ "$COMMAND" =~ refs/heads/$b ]]; then
+        PUSH_TARGETS_PROTECTED=true
+        break
       fi
     done
+    # Bare `git push` / `git push origin` with no ref (uses upstream from protected HEAD)
+    if [ "$PUSH_TARGETS_PROTECTED" = false ]; then
+      for b in "${PROTECTED_BRANCHES[@]}"; do
+        if [[ "$CURRENT_BRANCH" == "$b" ]] && {
+          [[ "$COMMAND" =~ ^git[[:space:]]+push$ ]] \
+          || [[ "$COMMAND" =~ ^git[[:space:]]+push[[:space:]]+origin$ ]];
+        }; then
+          PUSH_TARGETS_PROTECTED=true
+          break
+        fi
+      done
+    fi
+    if [ "$PUSH_TARGETS_PROTECTED" = true ] && [ "$LAND_MODE" != "1" ]; then
+      deny "BLOCKED: Direct push to protected branch is forbidden. Use kickoff-branch + release-branch (solo-local: scripts/land-branch.sh) or team-pr via gh."
+    fi
   fi
 
   # Conventional Commits for 'git commit'
   if [[ "$COMMAND" =~ git[[:space:]]+commit ]]; then
-    # Extract message from -m flag
     MSG=""
     if [[ "$COMMAND" =~ -m[[:space:]]+\"([^\"]+)\" ]]; then
       MSG="${BASH_REMATCH[1]}"
@@ -85,39 +101,20 @@ if [[ "$COMMAND" =~ git[[:space:]]+commit ]] || [[ "$COMMAND" =~ git[[:space:]]+
     if [ -n "$MSG" ]; then
       SUBJECT=$(echo "$MSG" | head -n 1)
       if [[ ! "$SUBJECT" =~ $CONVENTIONAL_COMMITS_REGEX ]]; then
-        REASON="BLOCKED: Commit message must follow Conventional Commits: <type>(<scope>): <subject>. Valid types: feat, fix, docs, style, refactor, perf, test, build, ci, chore."
-        if [ "$MODE" = "gemini" ]; then
-          jq -nc --arg reason "$REASON" '{decision: "deny", reason: $reason}'
-        else
-          echo "$REASON" >&2
-          exit 2
-        fi
-        exit 0
+        deny "BLOCKED: Commit message must follow Conventional Commits: <type>(<scope>): <subject>. Valid types: feat, fix, docs, style, refactor, perf, test, build, ci, chore."
       fi
 
       if [ ${#SUBJECT} -gt 72 ]; then
-        REASON="BLOCKED: Commit subject line must be 72 characters or less."
-        if [ "$MODE" = "gemini" ]; then
-          jq -nc --arg reason "$REASON" '{decision: "deny", reason: $reason}'
-        else
-          echo "$REASON" >&2
-          exit 2
-        fi
-        exit 0
+        deny "BLOCKED: Commit subject line must be 72 characters or less."
       fi
     fi
 
-    # Block direct commits to main
+    # Block direct commits to main unless land script is active
     for b in "${PROTECTED_BRANCHES[@]}"; do
       if [[ "$CURRENT_BRANCH" == "$b" ]]; then
-        REASON="BLOCKED: Direct commits to protected branch '$b' are forbidden. Use kickoff-branch to start a feature branch."
-        if [ "$MODE" = "gemini" ]; then
-          jq -nc --arg reason "$REASON" '{decision: "deny", reason: $reason}'
-        else
-          echo "$REASON" >&2
-          exit 2
+        if [ "$LAND_MODE" != "1" ]; then
+          deny "BLOCKED: Direct commits to protected branch '$b' are forbidden. Use kickoff-branch to start a feature branch, or scripts/land-branch.sh to integrate."
         fi
-        exit 0
       fi
     done
   fi

package/inspect-quality/SKILL.md

@@ -1,11 +1,12 @@
 ---
 name: inspect-quality
-description: Interactive QA session where user reports bugs or issues conversationally, and the agent logs them to specs/BUG-LOG.md with a structured audit schema. Explores the codebase in the background for context and domain language. Use when user wants to report bugs, do QA, or mentions "QA session".
+model: sonnet
+description: Interactive QA session where user reports bugs or issues conversationally, and the agent logs them to specs/bugs/BUG-LOG.md with a structured audit schema. Explores the codebase in the background for context and domain language. Use when user wants to report bugs, do QA, or mentions "QA session".
 ---
 
 # Inspect Quality
 
-Run an interactive QA session. The user describes problems they're encountering. You clarify, explore the codebase for context, and log each issue to `specs/BUG-LOG.md` with a structured, durable format.
+Run an interactive QA session. The user describes problems they're encountering. You clarify, explore the codebase for context, and log each issue to `specs/bugs/BUG-LOG.md` with a structured, durable format.
 
 ## For each issue the user raises
 
@@ -40,9 +41,9 @@ Keep as a single issue when:
 - It's one behavior that's wrong in one place
 - The symptoms are all caused by the same root behavior
 
-### 4. Log to specs/BUG-LOG.md
+### 4. Log to specs/bugs/BUG-LOG.md
 
-Append the issue to `specs/BUG-LOG.md`. Create the file and `specs/` directory if they don't exist.
+Append the issue to `specs/bugs/BUG-LOG.md`. Create the `specs/bugs/` directory if it doesn't exist.
 
 #### BUG-LOG.md format
 
@@ -50,7 +51,7 @@ The file maintains a Markdown table with the following columns (derived from str
 
 | Field | Description |
 |-------|-------------|
-| `bug_id` | `BUG-YYYY-MM-DD-NNN` |
+| `bug_id` | `BUG-YYYY-MM-DDTHHMMSS` |
 | `date` | `YYYY-MM-DD` |
 | `severity` | `critical` / `high` / `medium` / `low` |
 | `priority` | `p0` / `p1` / `p2` / `p3` |
@@ -69,6 +70,7 @@ The file maintains a Markdown table with the following columns (derived from str
 | `release_type` | `patch` / `minor` / `major` (filled in after fix) |
 | `commit_message` | Conventional Commits message (filled in after fix) |
 | `follow_ups` | semicolon-separated follow-up items |
+| `file` | path to detailed `specs/bugs/BUG-*.md` (filled in by investigate-bug) |
 | `status` | `open` / `in-progress` / `fixed` / `wont-fix` |
 
 When a bug is fixed (via `validate-fix`), update the relevant row with the resolution fields.
@@ -78,7 +80,7 @@ When a bug is fixed (via `validate-fix`), update the relevant row with the resol
 For each bug, also append a detail section:
 
 ```markdown
-### BUG-YYYY-MM-DD-NNN: [short title]
+### BUG-YYYY-MM-DDTHHMMSS: [short title]
 
 **What happened:** [actual behavior, plain language]
 **What I expected:** [expected behavior]
@@ -91,6 +93,7 @@ For each bug, also append a detail section:
 
 #### Rules for all entries
 
+- **bug_id** uses full timestamp: `BUG-YYYY-MM-DDTHHMMSS` — matches the individual bug file name in `specs/bugs/`
 - **No file paths or line numbers** — these go stale
 - **Use the project's domain language** (check `specs/UBIQUITOUS_LANGUAGE.md` if it exists)
 - **Describe behaviors, not code** — "the sync service fails to apply the patch" not "applyPatch() throws"

package/investigate-bug/SKILL.md

@@ -1,14 +1,23 @@
 ---
 name: investigate-bug
-description: Investigate a bug or issue by exploring the codebase to find root cause, then write a TDD-based fix plan to specs/DIAGNOSIS.md. Use when user reports a bug, wants to investigate a problem, mentions "triage", or wants to plan a fix.
+model: sonnet
+description: Investigate a bug or issue by exploring the codebase to find root cause, then write a TDD-based fix plan to specs/bugs/BUG-*.md. Use when user reports a bug, wants to investigate a problem, mentions "triage", or wants to plan a fix.
 ---
 
 # Investigate Bug
 
-Investigate a reported problem, find its root cause, and write a TDD fix plan to `specs/DIAGNOSIS.md`. This is a mostly hands-off workflow — minimize questions to the user.
+Investigate a reported problem, find its root cause, and write a TDD fix plan to `specs/bugs/BUG-*.md`. This is a mostly hands-off workflow — minimize questions to the user.
 
 ## Process
 
+### 0. Read previous bug history
+
+Before starting diagnosis:
+
+1. Read `specs/bugs/BUG-LOG.md` (if it exists) — check for prior bugs in the same `scope` or with similar symptoms.
+2. If a relevant prior bug is found, read the corresponding `specs/bugs/BUG-*.md` file to understand previous root cause analysis and fix approach.
+3. Note in your investigation whether this is a recurrence, a related issue, or novel.
+
 ### 1. Capture the problem
 
 Get a brief description of the issue from the user. If they haven't provided one, ask ONE question: "What's the problem you're seeing?"
@@ -58,12 +67,16 @@ Rules:
 - Include a final refactor step if needed
 - **Durability**: Only suggest fixes that would survive radical codebase changes. Tests assert on observable outcomes (API responses, UI state, user-visible effects), not internal state.
 
-### 5. Write specs/DIAGNOSIS.md
+### 5. Write the bug file
 
-Save the investigation and fix plan to `specs/DIAGNOSIS.md`. Create the `specs/` directory if it doesn't exist.
+Save the investigation and fix plan to `specs/bugs/BUG-YYYY-MM-DDTHHMMSS.md`. Create the `specs/bugs/` directory if it doesn't exist.
+
+After writing, append a row to `specs/bugs/BUG-LOG.md` with: bug_id (same timestamp), date, severity, priority, scope, summary, and file path. Create `specs/bugs/BUG-LOG.md` if it doesn't exist.
 
 <diagnosis-template>
 
+# BUG-YYYY-MM-DDTHHMMSS: [short title]
+
 ## Problem
 
 A clear description of the bug or issue, including:
@@ -108,4 +121,4 @@ A numbered list of RED-GREEN cycles:
 
 </diagnosis-template>
 
-After writing `specs/DIAGNOSIS.md`, print a one-line summary of the root cause and suggest running `kickoff-branch` next to create a fix branch.
+After writing the bug file, print a one-line summary of the root cause and suggest running `kickoff-branch` next to create a fix branch.

package/kickoff-branch/SKILL.md

@@ -1,5 +1,6 @@
 ---
 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".
 ---
 
@@ -17,14 +18,21 @@ Create an isolated working environment before touching any code. A clean baselin
 
 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. Check current state
+### 2. Anchor on default branch (main or master)
+
+> **HARD GATE** — Kickoff MUST start from an updated, clean default branch in the **primary** repository root (not a linked worktree).
 
 ```bash
-git status          # ensure working tree is clean
-git log --oneline -5  # confirm you're on the right base branch
+# Detect default branch
+DEFAULT=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@' || echo main)
+
+git checkout "$DEFAULT"
+git pull --ff-only origin "$DEFAULT"   # skip if no remote
+git status                             # working tree MUST be clean
+git log --oneline -5
 ```
 
-If working tree is dirty, ask the user to stash or commit first.
+If working tree is dirty, ask the user to stash or commit first. If not on `$DEFAULT` after checkout, stop and fix before continuing.
 
 ### 3. Pre-flight & Conflict Resolution
 
@@ -84,4 +92,4 @@ Worktree: ../<task-slug>
 Ready to develop.
 ```
 
-Suggest next skill: `develop-tdd` to start the TDD loop, or `execute-plan` if a specs/PLAN.md already exists.
+Suggest next skill: `develop-tdd` to start the TDD loop, or `execute-plan` if `specs/RELEASE-PLAN.md` already exists.

package/map-codebase/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: map-codebase
+model: sonnet
 description: "High-fidelity codebase surveying — analyzes stack, architecture, and gray areas (error handling, API shapes) and persists them into specs/CONTEXT.md. Goes beyond survey-context by identifying 'signals' for planning."
 ---
 

package/migrate-spec/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: migrate-spec
+model: sonnet
 description: Detect GSD, spec-kit, or BMAD spec artifacts in the current project and transform them into bigpowers format (specs/ directory, CONTEXT.md, SCOPE.md, TASKS.md, RELEASE-PLAN.md, ADRs). Use when user has an existing project with foreign spec docs and wants to adopt bigpowers conventions, or says "migrate", "import specs", "convert from GSD/BMAD/spec-kit".
 ---
 

package/model-domain/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: model-domain
+model: sonnet
 description: Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates specs/CONTEXT.md and specs/adr/ inline as decisions crystallise. Use when user wants to stress-test a plan against their project's domain language and documented decisions.
 ---
 
@@ -80,3 +81,12 @@ Only offer to create an ADR when all three are true:
 3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
 
 If any of the three is missing, skip the ADR. Use the format in [ADR-FORMAT.md](./ADR-FORMAT.md).
+
+## Concurrency safety audit
+
+When the plan touches shared state, async, or multi-threaded code:
+
+- [ ] List every **shared mutable** location (globals, singletons, module-level caches).
+- [ ] For each: who reads, who writes, synchronization mechanism (lock, actor, immutable copy).
+- [ ] Flag **race risks** (check-then-act, non-atomic read-modify-write) with severity.
+- [ ] Record findings in `specs/CONTEXT.md` under `## Concurrency` or in an ADR if architectural.

package/orchestrate-project/REFERENCE.md

@@ -30,15 +30,21 @@ Detailed documentation for the `orchestrate-project` meta-skill.
 
 ### PHASE 5: VERIFY
 - **Goal**: Validate success criteria and ensure production readiness.
-- **Deliverables**: `VERIFICATION.md`, audit results.
-- **Skills**: `validate-fix`, `audit-code`, `request-review`.
-- **Gate**: Quality ≥94%, coverage ≥95%, audits ≥93%.
+- **Deliverables**: UAT evidence, eval results.
+- **Skills**: `run-evals`, `verify-work`, `audit-code`, `request-review` (optional).
+- **Gate**: Verification Script confirmed; `verify-work` not on `main`/`master`.
 
-### PHASE 6: RELEASE
-- **Goal**: Ship to production with full traceability.
-- **Deliverables**: Release tag (vX.Y.Z), release notes.
+### PHASE 6: RELEASE (Integrate)
+- **Goal**: Ship to `main` with full traceability.
+- **Deliverables**: Release tag (vX.Y.Z), release notes via semantic-release.
 - **Skills**: `commit-message`, `release-branch`.
-- **Gate**: Safety ("About to push to main. Confirm?").
+- **Git arc**:
+  1. Plan on `main` (Discover / Plan)
+  2. `kickoff-branch` → worktree + feature branch + clean baseline
+  3. Build / Verify / Review on feature branch
+  4. Integrate: **solo-local** (`scripts/land-branch.sh`) or **team-pr** (`gh pr create` → squash merge)
+  5. Cleanup worktree; **end on `main`** in primary repo root
+- **Gate**: Safety ("About to land on main. Confirm?").
 
 ---
 

package/orchestrate-project/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: orchestrate-project
+model: sonnet
 description: Meta-skill that enforces the 6-phase core loop (discover → elaborate → plan → build → verify → release) with hard gates. Use to coordinate multi-phase projects with guaranteed quality checkpoints. One-time command for the entire project lifecycle.
 ---
 
@@ -34,14 +35,15 @@ See [REFERENCE.md](REFERENCE.md) for detailed phase specifications and gate type
 ## How Orchestrate Works
 
 1. **Maintains STATE.md** — Tracks current phase, artifacts, decisions, risks.
-2. **Spawns appropriate skills** — Calls survey-context, elaborate-spec, plan-work, etc.
-3. **Enforces gates** — Hard stops if success criteria not met.
-4. **The Gatekeeper** (v1.19.0) — Between every Story implementation in PHASE 4:
+2. **Spawns appropriate skills** — Reads each skill's `model:` frontmatter and routes (haiku/sonnet/opus). Calls survey-context, research-first, elaborate-spec, plan-work, develop-tdd, verify-work, run-evals, etc. Decisions pass only via `specs/STATE.md` between spawns.
+3. **Methodology lenses** — If `specs/METHODOLOGY.md` exists, apply active reasoning modes (STRIDE, Cost-of-Delay) at phase gates.
+4. **Enforces gates** — Hard stops if success criteria not met.
+5. **The Gatekeeper** (v1.19.0) — Between every Story implementation in PHASE 4:
    - READ `specs/RELEASE-PLAN.md` to verify completion.
    - REQUIRE that the previous Story is marked `[x] Done`.
    - REFUSE to call `update_topic` for a new Story until the previous one is physically evidenced as complete.
-5. **Pauses for confirmation** — After each phase, asks "Ready to proceed?".
-6. **Archives history** — Saves PLAN.md as specs/PLAN-vX.Y.Z.md.
+6. **Pauses for confirmation** — After each phase, asks "Ready to proceed?".
+7. **Archives history** — Saves RELEASE-PLAN snapshots as specs/RELEASE-PLAN-vX.Y.Z.md when needed.
 
 ## Orchestration Modes
 

package/organize-workspace/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: organize-workspace
+model: haiku
 description: Scans the active workspace for disposable artifacts—logs, caches, stale build output, and stray draft markdown—and proposes consolidation of scattered assets. Produces a reviewable list, asks for explicit confirmation before any delete or move, and optionally revises .gitignore. Use when the user says "clean my room", "organize workspace", "workspace cleanup", "remove temp files", "organize assets", "gitignore", or wants a safe tidy pass.
 ---
 

package/package.json

@@ -1,9 +1,10 @@
 {
   "name": "bigpowers",
-  "version": "1.0.0",
-  "description": "44 agent skills for spec-driven, test-first software development by solo developers",
+  "version": "1.1.0",
+  "description": "58 agent skills for spec-driven, test-first software development by solo developers",
   "main": "index.js",
   "scripts": {
+    "compliance": "bash scripts/audit-compliance.sh specs/audit/features",
     "sync": "bash scripts/sync-skills.sh",
     "install": "bash scripts/install.sh",
     "postinstall": "bash scripts/sync-skills.sh && bash scripts/install.sh",

package/plan-refactor/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: plan-refactor
+model: sonnet
 description: Create a detailed refactor plan with tiny commits via user interview, then save it as specs/REFACTOR.md. Use when user wants to plan a refactor, create a refactoring RFC, or break a refactor into safe incremental steps.
 ---
 

package/plan-release/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: plan-release
+model: sonnet
 description: Convert elaborated specs into a structured release plan with Gherkin acceptance criteria and WSJF-sorted epics. Produces specs/RELEASE-PLAN.md. Use when a spec is clear and ready to plan, after elaborate-spec, or when the user wants a release plan broken into epics and stories.
 ---
 

package/plan-work/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: plan-work
+model: opus
 description: Write a detailed implementation plan to specs/RELEASE-PLAN.md. Every step must include a runnable verify command (Karpathy verification template). Use when user has a task to implement and needs a step-by-step plan with evidence checkpoints, or after plan-release produces specs/RELEASE-PLAN.md.
 ---
 
@@ -36,6 +37,8 @@ If this plan touches an existing module or symbol, run `assess-impact` first to
 
 > **COMPLEXITY PUSHBACK (HARD GATE)** — Every step introducing a new abstraction (class, interface, helper, layer) MUST include a one-sentence "Reason for Depth": _"This abstraction is needed because [forcing function]..."_. If the sentence cannot be filled with a non-trivial reason, the abstraction is premature. Delete it and use inline code instead.
 
+> **SLOPCHECK (HARD GATE)** — For every external package proposed in the plan, run slopcheck (or manual registry check) and tag: `[OK]`, `[SUS]`, or `[SLOP]`. `[SUS]` and `[SLOP]` require explicit human approval before the step may execute. Document tags inline next to the package name.
+
 ## Process
 
 ### 1. Explore the codebase
@@ -63,15 +66,17 @@ Append the detailed steps under the relevant story in `specs/RELEASE-PLAN.md`. C
 
 ### Story [X.Y]: [title] — Implementation Steps
 
+**type:** feat | fix | refactor  
+**context:** domain | infra  
 **Context**: [One paragraph: what this story implements and why]
 
 ## Steps
 
-1. [Step description] → verify: `<runnable command>`
+1. [Step description] (ref: ADR-NNNN or commit SHA) → verify: `<runnable command>`
 
-2. [Step description] → verify: `<runnable command>`
+2. [Step description] (ref: ADR-NNNN or commit SHA) → verify: `<runnable command>`
 
-3. [Step description] → verify: `<runnable command>`
+3. [Step description] (ref: ADR-NNNN or commit SHA) → verify: `<runnable command>`
 
 ...
 

package/profiles/node-service.md

@@ -0,0 +1,28 @@
+# Stack Profile: Node Service
+
+Opt-in conventions fragment for `seed-conventions`.
+
+## Commands
+
+| Action | Command |
+|--------|---------|
+| Test | `npm test` |
+| Lint | `npm run lint` |
+| Build | `npm run build` (if applicable) |
+| Run | `node dist/index.js` or `npm start` |
+
+## Architecture
+
+- Layered: routes → handlers → services → repositories
+- Structured JSON logging (see `wire-observability`)
+
+## Conventions
+
+- ESM or CJS — match existing `package.json` `"type"`
+- Environment via `process.env` validated at boot
+- Integration tests hit HTTP with supertest or fetch
+
+## Never
+
+- Never log secrets or full auth tokens
+- Never use `any` on public API types

package/profiles/solo-git.md

@@ -0,0 +1,39 @@
+# Stack Profile: Solo Git (local squash land)
+
+Opt-in git integrate profile for solo developers. Keeps protected `main`, worktrees, and verification gates; drops PR ceremony as the default ship path.
+
+## When to use
+
+- Working alone; PR UI feels like overhead
+- You still want Conventional Commits, semantic-release, and no direct work on `main`
+- Remote CI on PR is optional, not required every task
+
+## Integrate
+
+| Setting | Value |
+|---------|--------|
+| Mode | `release-branch` → **solo-local** |
+| Ship script | `bash scripts/land-branch.sh <branch> "<message>"` |
+| PR | Opt-in only (team-pr / branch protection) |
+| End state | Primary repo on `main`, worktree removed |
+
+## Day-to-day arc
+
+1. **On main:** `survey-context` → plan skills → `kickoff-branch` (forces clean, updated `main`)
+2. **In worktree:** `develop-tdd` / `execute-plan` → `run-evals` → `verify-work` → `audit-code` → `commit-message`
+3. **Integrate:** `release-branch` (solo-local) → `scripts/land-branch.sh`
+4. **Done when:** `git branch --show-current` is `main`, feature worktree gone
+
+## Hooks
+
+Install via `guard-git`. Hooks block commits/pushes to `main` unless `GIT_BIGPOWERS_LAND=1` (set only by `land-branch.sh`).
+
+## Register in project
+
+Run `compose-workflow` or copy `specs/WORKFLOW-solo-git.md` and note in `specs/STATE.md` Active Decisions.
+
+## Never
+
+- Never land without `release-branch` §1–3 gates (tests, coverage, diff review)
+- Never commit on `main` outside `land-branch.sh`
+- Never skip `kickoff-branch` for feature work

package/profiles/swift.md

@@ -0,0 +1,27 @@
+# Stack Profile: Swift
+
+Opt-in conventions fragment for `seed-conventions`. Core bigpowers skills stay language-agnostic.
+
+## Commands (defaults — override in interview)
+
+| Action | Command |
+|--------|---------|
+| Test | `swift test` |
+| Lint | `swiftlint` (if `.swiftlint.yml` exists) |
+| Build | `swift build` |
+
+## Architecture
+
+- Prefer MVVM: View → ViewModel → Model/Service
+- Protocol-oriented seams for testability
+
+## Conventions
+
+- Use `struct` for value types; `class` only when reference semantics required
+- Async: `async/await`; avoid callback pyramids
+- Naming: Swift API Design Guidelines (camelCase, clarity at call site)
+
+## Never
+
+- Never force-unwrap (`!`) in production paths without documented invariant
+- Never commit `DerivedData/` or `.build/`

package/profiles/typescript-vue.md

@@ -0,0 +1,28 @@
+# Stack Profile: TypeScript + Vue
+
+Opt-in conventions fragment for `seed-conventions`.
+
+## Commands
+
+| Action | Command |
+|--------|---------|
+| Test | `npm run test` or `vitest run` |
+| Lint | `npm run lint` |
+| Build | `npm run build` |
+| Dev | `npm run dev` |
+
+## Architecture
+
+- Vue 3 Composition API + `<script setup>`
+- Pinia for shared state; composables for reusable logic
+
+## Conventions
+
+- SFC order: `<script setup>` → `<template>` → `<style scoped>`
+- Prettier for format; named exports in composables
+- Vitest for unit tests; Vue Test Utils for components
+
+## Never
+
+- Never use Options API for new components unless extending legacy
+- Never commit `dist/`, `node_modules/`, `.env`