configs-all 1.0.0

package/claude/commands/context.md

@@ -0,0 +1,112 @@
+## Repo & Machine Context Snapshot
+
+Build a comprehensive, persistent context document for the current repository. This is a knowledge snapshot that future Claude sessions read first to avoid redundant exploration and reduce token costs.
+
+**Do NOT delegate this command to a subagent.** This is an orchestration command — Opus runs it directly.
+
+### Input
+$ARGUMENTS - optional focus area (e.g., "frontend", "deployment pipeline"). If omitted, builds full repo context.
+
+### Instructions
+
+1. **Read existing documentation first:**
+   - Read the project CLAUDE.md if it exists
+   - Read ALL files in `docs/research/` if the directory exists
+   - Read ALL files in `docs/context/` if the directory exists — if a context doc already exists for this repo, you will UPDATE it rather than creating a duplicate
+   - Read MEMORY.md if accessible
+
+2. **Gather comprehensive context** using parallel Explore subagents for independent areas:
+
+   **Project identity:**
+   - Tech stack (detect from package.json, requirements.txt, Makefile, Cargo.toml, go.mod, etc.)
+   - Project structure — key directories and their roles (not just a file listing)
+   - Entry points (main files, index files, CLI entry points)
+
+   **Architecture:**
+   - How the codebase is organized (monorepo? modular? layered?)
+   - Key abstractions and patterns used
+   - Data flow for the primary use case
+
+   **Development workflow:**
+   - How to build, test, lint, format (exact commands)
+   - CI/CD pipeline if present
+   - Deploy process if present
+   - Environment variables and configuration
+
+   **Testing infrastructure:**
+   - Test framework and how to run tests
+   - Test coverage and quality assessment
+   - Key test files and what they cover
+
+   **Dependencies:**
+   - Critical internal dependencies (what depends on what)
+   - External dependencies and their roles
+   - Version constraints that matter
+
+   **Environment:**
+   - Current machine/hostname and platform
+   - Available tools (node, python, docker, kubectl, etc.)
+   - Machine-specific quirks if known from MEMORY.md
+
+   **Recent trajectory:**
+   - Last 20-30 git commits to understand current direction
+   - Any in-progress branches or uncommitted work
+   - Recent patterns in what's being changed
+
+   **Gotchas:**
+   - Non-obvious behavior, implicit assumptions
+   - Tech debt or fragile areas
+   - Things that have broken before (from git history or docs)
+
+3. **Verify ALL findings against actual code — this is non-negotiable.** Documentation goes stale. The value of this entire system depends on context docs being accurate.
+   - Read key source files to confirm architectural claims
+   - Run actual commands to verify build/test/lint instructions still work (e.g., `npm test --help`, `cat package.json | grep scripts`)
+   - Check git log since the last context doc update — have key files changed?
+   - If an existing context doc says "tests use Jest" but you find Vitest in package.json, update accordingly
+   - If a documented command no longer works, fix the doc immediately
+   - **Every claim in the output doc must be verified against current reality, not copied from a previous doc**
+
+4. **Write or update** `docs/context/YYYY-MM-DD-<repo-name>.md`:
+
+   ```markdown
+   # Context: <Repo Name>
+   _Last updated: YYYY-MM-DD_
+   _Machine: <hostname>_
+   _Platform: <macOS/Linux/WSL>_
+
+   ## Overview
+   What this project does in 2-3 sentences.
+
+   ## Tech Stack
+   Languages, frameworks, key libraries with versions.
+
+   ## Project Structure
+   Key directories and their roles. Not a full file listing — focus on what matters.
+
+   ## Architecture
+   How the pieces fit together. Key patterns and conventions.
+
+   ## Development Workflow
+   Exact commands to build, test, lint, format, deploy.
+
+   ## Testing
+   Framework, how to run, coverage, key test files.
+
+   ## Dependencies
+   Critical internal and external dependencies.
+
+   ## Environment
+   Machine-specific context, available tools, quirks.
+
+   ## Recent Trajectory
+   What's been changing recently, current direction.
+
+   ## Gotchas
+   Non-obvious behavior, fragile areas, things that break.
+   ```
+
+   Omit sections that don't apply. Add sections if the repo warrants it.
+
+5. **If updating an existing context doc:** Preserve the original date in the filename but update the `_Last updated_` field. Only change sections where reality has diverged from what's documented.
+
+6. Report the file path and a brief summary of what was captured (or what changed if updating).

package/claude/commands/dash.md

@@ -0,0 +1,37 @@
+## Quick Dashboard
+
+**IMPORTANT: Immediately delegate this entire task to a subagent using the Agent tool with `model: "haiku"` and `subagent_type: "general-purpose"`.** Do not perform operations yourself. Pass the full prompt below to the subagent and relay its result.
+
+### Subagent prompt
+
+You are generating a quick status dashboard — 5-second situational awareness. Run ALL checks in parallel for speed.
+
+1. **Run in parallel:**
+   - `git branch --show-current` — current branch
+   - `git status --short` — uncommitted changes (just the summary)
+   - `git log --oneline -5` — last 5 commits
+   - `git stash list` — any stashed work
+   - Check if `docs/plans/` exists and scan for `_Status: PENDING_` or `_Status: IN PROGRESS_` plans (just filenames and status, don't read full content)
+   - Check if `docs/handoff/` exists and get the most recent file's date
+   - `gh pr list --author @me --limit 5 2>/dev/null` — open PRs (skip if gh not available)
+
+2. **Format as a compact dashboard:**
+
+   ```
+   ┌─ Dashboard ──────────────────────────────────
+   │ Branch:    feat/my-feature
+   │ Changes:   3 modified, 1 untracked
+   │ Stashes:   none
+   │
+   │ Recent commits:
+   │   abc1234 feat: add webhook support
+   │   def5678 fix: resolve auth timeout
+   │   ghi9012 chore: update deps
+   │
+   │ Plans:     2 pending, 1 in progress
+   │ Handoff:   2026-02-28 (yesterday)
+   │ Open PRs:  1 (CI passing)
+   └──────────────────────────────────────────────
+   ```
+
+3. Keep it SHORT. No explanations, no recommendations — just facts. This is a glance, not a briefing. If something needs attention (failing CI, stale handoff, blocked plans), mark it with [!] but don't elaborate.

package/claude/commands/deploy-check.md

@@ -0,0 +1,37 @@
+## Deployment Verification
+
+**IMPORTANT: Immediately delegate this entire task to a subagent using the Agent tool with `model: "haiku"` and `subagent_type: "general-purpose"`.** Do not run any kubectl commands yourself. Pass the full prompt below to the subagent and relay its result.
+
+### Input
+$ARGUMENTS - deployment name and namespace (e.g., "my-app staging")
+
+### Subagent prompt
+
+You are verifying a deployment is healthy. The deployment info is: $ARGUMENTS
+
+1. Check deployment rollout status:
+   ```
+   kubectl rollout status deployment/<name> -n <namespace> --timeout=120s
+   ```
+
+2. Verify all pods are Running and Ready:
+   ```
+   kubectl get pods -l app=<name> -n <namespace>
+   ```
+
+3. Check for recent restarts or CrashLoopBackOff:
+   ```
+   kubectl get pods -l app=<name> -n <namespace> -o jsonpath='{range .items[*]}{.metadata.name}{" restarts: "}{.status.containerStatuses[0].restartCount}{"\n"}{end}'
+   ```
+
+4. Tail recent logs for errors:
+   ```
+   kubectl logs deployment/<name> -n <namespace> --tail=50
+   ```
+
+5. Verify ConfigMaps and Secrets are mounted correctly:
+   ```
+   kubectl describe pod -l app=<name> -n <namespace> | grep -A5 "Mounts\|Volumes"
+   ```
+
+6. Report health status with a clear **HEALTHY** / **UNHEALTHY** verdict and any warnings.

package/claude/commands/deps.md

@@ -0,0 +1,26 @@
+## Check Dependencies
+
+**IMPORTANT: Immediately delegate this entire task to a subagent using the Agent tool with `model: "haiku"` and `subagent_type: "general-purpose"`.** Do not run any commands yourself. Pass the full prompt below to the subagent and relay its result.
+
+### Subagent prompt
+
+You are checking for outdated dependencies and reporting what needs updating.
+
+1. Detect the project type:
+   - `package.json` → Node/TS project
+   - `pyproject.toml` / `requirements.txt` → Python project
+   - Both → check both
+
+2. For Node/TS projects:
+   - Run `npm outdated` to list outdated packages
+   - Categorize as: patch (safe), minor (likely safe), major (breaking changes possible)
+
+3. For Python projects:
+   - Run `pip list --outdated` or `pip-audit` if available
+   - Note any known security vulnerabilities
+
+4. Report a summary table:
+   - Package name | Current | Latest | Update type (patch/minor/major)
+   - Highlight any security-related updates
+
+5. Do NOT update anything — just report. Let the user decide what to update.

package/claude/commands/duplo.md

@@ -0,0 +1,56 @@
+## Remote Work on duplo (Work Mac via SSH)
+
+Execute tasks on duplo remotely over SSH. The purpose is to use the user's **personal Claude account on this machine** to do work on duplo's repos — without needing Claude signed in on duplo.
+
+**CRITICAL: YOU are the agent doing the work.** All slash commands, research, file edits, and coding tasks referenced in $ARGUMENTS are executed by THIS Claude session. SSH is your transport layer for reading files, running commands, and writing files on duplo. NEVER launch, prompt, or invoke Claude Code on duplo itself (no `ssh duplo claude ...`, no `ssh -t duplo claude ...`). If the user says "run /init on that project", YOU run the /init workflow by SSHing into duplo to explore files, then writing artifacts via SSH.
+
+### Input
+$ARGUMENTS - what to do on duplo (e.g., "check git status on duplo-ui", "run tests in ai-ops", "deploy configs", "run /init on xterm repo", "create a CLAUDE.md for marketplace")
+
+### Connection
+- **SSH host**: `duplo` (Tailscale: 100.83.140.62)
+- **User**: `mikl`
+- **Environment**: macOS, zsh, Homebrew, Node.js, Python, git
+- **Shell**: Non-interactive SSH gets minimal PATH. Use `zsh -lc '...'` when commands need homebrew/node/npm.
+
+### Key Paths on duplo
+- **Home**: `/Users/mikl`
+- **Configs repo**: `~/Dropbox/duplo/dev/chiefmikey/configs`
+- **Work repos**: `~/Dropbox/duplo/dev/` — subdirs: `ai/`, `prod/`, `tools/`, `duplo-ui/`, `duplo-infra/`
+- **Claude config**: `~/.claude/`
+
+### Environment Notes
+- Git user: `chiefmikey` (work identity, 1Password signing)
+- 1Password SSH agent for keys
+
+### Config Sync
+The configs repo on duplo is at `~/Dropbox/duplo/dev/chiefmikey/configs`. Sync via git:
+1. **Before duplo work**: Commit and push any config changes locally first
+2. **Pull on duplo**: `ssh duplo "cd ~/Dropbox/duplo/dev/chiefmikey/configs && git pull origin main"`
+3. **Deploy**: `ssh duplo "cd ~/Dropbox/duplo/dev/chiefmikey/configs && zsh scripts/sync/push-configs.zsh"`
+
+Always sync configs at the start of a session if any config files have been modified locally.
+
+### Execution Rules
+1. **YOU do all the work from this machine over SSH.** Never launch Claude on duplo.
+2. Use `ssh duplo` for all commands. Use `zsh -lc '...'` when commands need full PATH.
+3. For multi-command workflows, chain with `&&` or use a heredoc:
+   ```
+   ssh duplo bash -s <<'REMOTE'
+   command1
+   command2
+   REMOTE
+   ```
+4. To read files: `ssh duplo "cat /path/to/file"`
+5. To write files: `ssh duplo "cat > /path/to/file << 'EOF'\n...\nEOF"`
+6. To explore repos: `ssh duplo "ls ..."`, `ssh duplo "find ..."`, `ssh duplo "grep ..."`
+7. When $ARGUMENTS references a slash command (e.g., "/init", "/research", "/prep"), invoke that skill in THIS session and use SSH as the transport to interact with the remote project's files.
+8. Always show command output to the user so they can see what happened.
+9. Do the work — don't just explain what to do. Execute the commands remotely.
+
+### Steps
+1. If config files were changed locally, commit and push first, then pull and push-configs on duplo
+2. Parse what the user wants done on duplo from $ARGUMENTS
+3. If a slash command is referenced, invoke the skill here and execute it against the remote repo via SSH
+4. Connect via SSH and execute the task
+5. Report results

package/claude/commands/explain.md

@@ -0,0 +1,43 @@
+## Explain Code
+
+**Before delegating, gather project context:**
+1. Check if `docs/context/` has a context snapshot — if so, read the most recent one and extract the Architecture and Project Structure sections
+2. Check if `docs/research/` has research relevant to the target area — if so, read it
+3. Read the project CLAUDE.md if it exists
+4. Pass this context to the subagent below
+
+**Then delegate this task to a subagent using the Agent tool with `model: "sonnet"` and `subagent_type: "general-purpose"`.** Pass the full prompt below (with context injected) to the subagent and relay its result.
+
+### Input
+$ARGUMENTS - optional: file path, function name, or description of what to explain (e.g., "src/auth/middleware.ts", "the push-configs sync flow"). If omitted, explains the most recently changed code.
+
+### Subagent prompt
+
+You are explaining code to a senior engineer who wants a quick, accurate understanding.
+
+**If no target was provided (`$ARGUMENTS` is empty), auto-detect:**
+- Check `git diff --name-only` for uncommitted changes — explain the most complex changed file
+- If no uncommitted changes: check `git log --oneline -1 --name-only` — explain the files from the last commit
+- Focus on the file with the most significant changes (largest diff or most complex logic)
+
+**If a target was provided:** Target: $ARGUMENTS
+
+**Project Context:**
+[Inject Architecture, Project Structure from docs/context if available]
+[Inject relevant research from docs/research if available]
+[Inject project CLAUDE.md overview if available]
+If no project context is available, infer from the codebase.
+
+1. Find and read the relevant code:
+   - If a file path was given, read it
+   - If a function/class name was given, search for it with grep/glob then read it
+   - If a description was given, find the most relevant files
+
+2. Provide a structured explanation:
+   - **Purpose:** What does this code do? (1-2 sentences)
+   - **How it works:** Walk through the key logic steps
+   - **Where it fits:** How this piece connects to the broader architecture (use project context)
+   - **Dependencies:** What does it depend on? What depends on it?
+   - **Key details:** Edge cases, gotchas, or non-obvious behavior worth knowing
+
+3. Keep it concise. Don't explain basic language features — focus on the domain logic and architecture decisions. Use file:line references for key points.

package/claude/commands/fix-and-test.md

@@ -0,0 +1,46 @@
+## Fix and Test
+
+**Before delegating, gather project context:**
+1. Check if `docs/context/` has a context snapshot — if so, read the most recent one and extract the Architecture, Development Workflow, Testing, and Gotchas sections
+2. Read the project CLAUDE.md if it exists — extract Tech Stack, Commands, and Common Mistakes sections
+3. Check `docs/incidents/` for past incidents related to this error — has this bug happened before? If so, include the prior root cause and fix
+4. Pass this context to the subagent below
+
+**Then delegate this task to a subagent using the Agent tool with `model: "sonnet"` and `subagent_type: "general-purpose"`.** Pass the full prompt below (with context injected) to the subagent and relay its result.
+
+### Input
+$ARGUMENTS - optional: error message, bug description, or file path with issue. If omitted, auto-detects issues to fix.
+
+### Subagent prompt
+
+You are doing a quick bugfix: diagnose, fix, verify.
+
+**If no issue was provided (`$ARGUMENTS` is empty), auto-detect:**
+- Run the test suite — if any tests fail, fix the first failure
+- Run lint/build — if errors exist, fix them
+- Check `docs/incidents/` for `_Status: ACTIVE_` incidents — pick up the most recent one
+- If nothing is broken: report "All tests pass, build clean, no active incidents. Nothing to fix."
+
+**If an issue was provided:** The issue is: $ARGUMENTS
+
+**Project Context:**
+[Inject Architecture, Development Workflow, Testing, Gotchas from docs/context if available]
+[Inject Tech Stack, Commands, Common Mistakes from project CLAUDE.md if available]
+If no project context is available, detect the tech stack from the codebase.
+
+1. **Diagnose:** Read the relevant code. If an error message is provided, trace it to the root cause. Use project context to understand how the affected code fits into the broader architecture.
+
+2. **Fix:** Make the minimal correct fix. Don't refactor unrelated code. Ensure the fix follows project conventions (from context above).
+
+3. **Test:** Run the relevant test suite using exact commands from the project context if available. Otherwise:
+   - TypeScript: `npx jest <relevant-test-file>` or `npm test`
+   - Python: `pytest <relevant-test-file> -v`
+   - Angular: `npx ng test --watch=false`
+
+4. **Verify build:**
+   - TypeScript: `npx tsc --noEmit`
+   - Python: `python -m py_compile <file>`
+
+5. If tests fail, iterate on the fix until they pass.
+
+6. Show the diff of changes made and confirm all tests pass.

package/claude/commands/game-debug.md

@@ -0,0 +1,66 @@
+## Game & Shader Debugging (Windows PowerShell)
+
+You are debugging game, GPU, or ReShade shader issues on a Windows PC. You have access to custom PowerShell debug helper commands.
+
+### Invocation
+
+Claude Code runs in bash, NOT PowerShell. The debug helpers are PowerShell functions defined in the user's profile. Use the wrapper script to invoke them:
+
+```bash
+powershell -NoProfile -ExecutionPolicy Bypass -File 'C:\Users\wolfe\.claude\scripts\psdebug.ps1' <FunctionName> [args...]
+```
+
+### Available Commands
+
+| Function | Alias | Purpose |
+|----------|-------|---------|
+| `Get-GpuInfo` | `gpu-info` | GPU adapters, driver version, VRAM, nvidia-smi output |
+| `Get-DxDiag` | `dx-diag` | Full DirectX diagnostic dump (takes ~8 seconds) |
+| `Get-GameProcesses` | `game-procs` | Running game/GPU/Steam/ReShade processes with memory & CPU usage |
+| `Find-ReshadeLogs` | `reshade-logs` | Find and display recent ReShade.log files across Steam libraries |
+| `Find-ReshadeLogs -GamePath '"C:\path\to\game"'` | | Search a specific game directory |
+| `Find-ReshadeShaders` | `reshade-shaders` | List ReShade shader directories, count .fx and texture files |
+| `Find-ReshadeShaders -GamePath '"C:\path\to\game"'` | | Check specific game's shaders |
+| `Get-SteamLogs` | `steam-logs` | Recent Steam log entries |
+| `Get-GameCrashLogs` | `crash-logs` | Windows Event Viewer errors: app crashes, GPU resets, driver failures |
+| `Get-GameCrashLogs -Hours 2` | | Narrow to last N hours |
+| `Get-DebugSummary` | `debug-summary` | One-shot overview: GPU + running games + recent crashes |
+
+**Always use the full function name** (e.g., `Get-DebugSummary`) when invoking via the wrapper, not the alias.
+
+### Examples
+
+```bash
+# Quick system overview
+powershell -NoProfile -ExecutionPolicy Bypass -File 'C:\Users\wolfe\.claude\scripts\psdebug.ps1' Get-DebugSummary
+
+# Check ReShade logs for a specific game
+powershell -NoProfile -ExecutionPolicy Bypass -File 'C:\Users\wolfe\.claude\scripts\psdebug.ps1' Find-ReshadeLogs -GamePath '"C:\Program Files (x86)\Steam\steamapps\common\Fable Anniversary"'
+
+# Last 2 hours of crash logs
+powershell -NoProfile -ExecutionPolicy Bypass -File 'C:\Users\wolfe\.claude\scripts\psdebug.ps1' Get-GameCrashLogs -Hours 2
+```
+
+### Debugging Workflow
+
+1. **Start with** `Get-DebugSummary` to get a quick overview of GPU state, running processes, and recent errors
+2. **If the game is running**, use `Get-GameProcesses` to check its process state, memory usage, and whether ReShade is loaded
+3. **For visual issues**, ask the user to paste a screenshot (Ctrl+V) — you cannot see the screen
+4. **For ReShade problems**, check `Find-ReshadeLogs` first for shader compilation errors, then `Find-ReshadeShaders` to verify shader files exist
+5. **For crashes/freezes**, check `Get-GameCrashLogs` for GPU driver resets (nvlddmkm), application faults, or kernel-power events
+6. **For performance issues**, combine `Get-GpuInfo` (driver version, VRAM) with `Get-GameProcesses` (memory pressure)
+
+### Key Paths
+
+- Steam default: `C:\Program Files (x86)\Steam\steamapps\common\`
+- Additional Steam libraries may be on D: or E: drives
+- ReShade configs: typically `ReShade.ini` next to the game .exe
+- ReShade shaders: typically `reshade-shaders\` next to the game .exe
+- ReShade logs: `ReShade.log` next to the game .exe
+
+### Notes
+
+- Claude Code runs in **bash** (Git Bash) — always invoke via the `psdebug.ps1` wrapper
+- Use Windows paths (backslashes) inside PowerShell arguments
+- User may paste screenshots of visual glitches — analyze them carefully
+- If a game directory is needed, ask the user for the game name and check the Steam common directory

package/claude/commands/games.md

@@ -0,0 +1,53 @@
+## Remote Work on Games PC (1TB Isolated Boot Drive)
+
+Execute tasks on the gaming PC remotely over SSH from the current machine.
+
+### Input
+$ARGUMENTS - what to do on the gaming PC (e.g., "install a game launcher", "check disk space", "run the boot script")
+
+### Connection
+- **SSH host**: `games` (Tailscale: 100.84.16.17)
+- **User**: `relax`
+- **Environment**: Native Windows 11 (no WSL)
+- **Shell**: Default SSH shell is **cmd.exe**. Use `powershell -Command "..."` or `powershell -File <script>` for PowerShell.
+
+### Key Paths on PC
+- **Home**: `C:\Users\relax`
+- **Boot scripts**: `D:\scripts\` (8TB shared drive — also visible as `B:\` when booted to the 4TB main host)
+- **Start Menu shortcuts**: `%APPDATA%\Microsoft\Windows\Start Menu\Programs\Boot\`
+
+### Drive Layout (from 1TB perspective)
+| Letter | Size | Device |
+|--------|------|--------|
+| C: | 837GB | 990 PRO 1TB (this OS) |
+| D: | 7.4TB | WDC 8TB HDD (Backup, shared with 4TB) |
+| E: | 3.3TB | 990 PRO 4TB (main host, visible but not booted) |
+
+### Boot Switching
+- **1TB → 4TB**: Normal restart (4TB is default boot)
+- **1TB → 1TB** (e.g., after Windows Update): Start Menu → "Boot to 1TB" or `D:\scripts\Boot-To-1TB.ps1` (requires admin)
+- **BIOS access**: Start Menu → "Boot to BIOS" or `D:\scripts\Boot-To-BIOS.ps1`
+- Mechanism: `bcdedit /set {fwbootmgr} bootsequence {bootmgr}` — one-time boot override, consumed on next restart
+
+### Environment Notes
+- This is an isolated gaming/testing Windows install — minimal dev tools
+- No WSL installed, no git, no Node.js — pure Windows environment
+- The 4TB main host (mikpc) is a separate Tailscale device; both can't be online simultaneously since they share the same physical machine
+- SSH server: Windows OpenSSH, MaxAuthTries 10, pubkey auth via 1Password key in `C:\ProgramData\ssh\administrators_authorized_keys`
+
+### Execution Rules
+1. Use `ssh games` for all commands. Default shell is cmd.exe.
+2. For PowerShell, use: `ssh games "powershell -Command \"...\""` or write a .ps1 file and execute via `powershell -File`.
+3. For complex multi-command workflows, write a .ps1 script to `D:\scripts\` and run it:
+   ```
+   cat script.ps1 | ssh games "powershell -Command \"\$input | Set-Content -Path 'D:\\scripts\\temp.ps1' -Encoding Ascii\""
+   ssh games "powershell -ExecutionPolicy Bypass -File D:\scripts\temp.ps1"
+   ```
+4. Always show command output to the user so they can see what happened.
+5. Do the work - don't just explain what to do. Execute the commands remotely.
+6. Remember: escaping through SSH → cmd → PowerShell is painful. Prefer writing script files over inline commands when complexity is non-trivial.
+
+### Steps
+1. Parse what the user wants done on the gaming PC from $ARGUMENTS
+2. Connect via SSH and execute the task
+3. Report results

package/claude/commands/go.md

@@ -0,0 +1,147 @@
+## Execute Plan to Completion
+
+Read the latest implementation plan (or a specified one) and execute it autonomously to 100% completion. Every step is verified. Every claim is backed by evidence. Does not stop until the task is fully done and proven.
+
+### Input
+$ARGUMENTS - optional path to a specific plan file. If omitted, executes ALL pending plans in `docs/plans/` (oldest first).
+
+### Instructions
+
+1. **Load the plan(s):**
+   - If `$ARGUMENTS` specifies a file, read and execute that single plan
+   - Otherwise, scan ALL `.md` files in `docs/plans/` and read each file's status:
+     - `_Status: PENDING_` or no status marker → queued for execution
+     - `_Status: IN PROGRESS_` → resume this one first (was interrupted)
+     - `_Status: COMPLETED_` → skip
+   - Sort pending plans by date (oldest first — execute in the order they were created)
+   - If no pending plans exist, stop and tell the user to run `/prep` or `/plans` first
+   - Report the queue: "Found N pending plans. Executing in order: [list]"
+
+2. **Load and verify supporting context:**
+   - Read the `_Context:_` and `_Research:_` files referenced in the plan header
+   - Read the project CLAUDE.md if it exists
+   - Check `docs/spikes/` for any spikes related to this plan's area — leverage settled decisions
+   - Check `docs/incidents/` for past incidents in this area — avoid repeating past failures
+   - **Staleness check:** For each referenced doc, verify key claims against current code:
+     - Check that files/directories mentioned still exist and have the expected structure
+     - Check that key functions/APIs referenced in the plan still have the expected signatures
+     - Check recent git log since the doc's date — have relevant files changed significantly?
+   - If stale info is found: update the doc, then adjust the plan steps as needed before executing
+   - This gives the executing agents verified, current situational awareness
+
+3. **Analyze plan independence** (when executing multiple plans):
+   - Read the Files section of each pending plan
+   - Plans that touch entirely different files/directories are **independent** — can run in parallel
+   - Plans that share any files are **dependent** — must run sequentially
+   - Group independent plans for parallel execution, sequence dependent ones
+   - Report the execution strategy: "Plans A and B are independent (parallel). Plan C depends on A (sequential after A)."
+
+4. **For each plan (or parallel group), execute:**
+
+   a. **Mark the plan as in progress:**
+      - Change `_Status: PENDING_` to `_Status: IN PROGRESS_`
+      - This ensures interrupted plans are resumed first on the next `/go` run
+
+   b. **Check for resume point:**
+      - Read `_LastCompletedStep: N_` from the plan header
+      - If N > 0, this plan was interrupted — skip steps 1 through N
+      - Read the Execution Journal (if it exists) for context on prior attempts
+      - Report: "Resuming from step N+1 (steps 1-N already completed)"
+
+   c. **Review the plan critically** before starting:
+      - Are there any steps that seem wrong or outdated given current code?
+      - Are there missing dependencies between steps?
+      - If resuming: verify completed steps are still valid (code hasn't been reverted)
+      - If issues are found, fix the plan first, then execute the corrected version
+
+   d. **Execute each step using subagent-driven development:**
+
+      For each step in the plan (starting from the resume point):
+
+      i. **Dispatch implementer subagent** (Agent tool, `subagent_type: "general-purpose"`):
+         - Provide the step details (file, what, why, code, verify)
+         - Provide relevant context from the loaded docs
+         - If Execution Journal has prior failures for this step, include that context
+         - Implementer implements the change, runs the step's verify command, and commits
+
+      ii. **Dispatch spec compliance reviewer** (Agent tool, `subagent_type: "general-purpose"`):
+         - Does the implementation match exactly what the plan specified?
+         - Are there deviations, missing pieces, or incorrect implementations?
+         - If issues: implementer fixes them before proceeding
+
+      iii. **Dispatch code quality reviewer** (Agent tool, `subagent_type: "general-purpose"`):
+         - Does the code follow project conventions and patterns?
+         - Architecture, naming, error handling all sound?
+         - If issues: implementer fixes them before proceeding
+
+      iv. **Verify the step** — run the step's verify command independently (don't trust the subagent's claim)
+
+      v. **Update progress tracking** after each step completes:
+         - Update `_LastCompletedStep: N_` in the plan header
+         - Append to the Execution Journal:
+           ```markdown
+           ### Step N: [Title] — COMPLETED
+           - Completed at: YYYY-MM-DD HH:MM
+           - Result: [1-line summary of what was done]
+           ```
+         - If the step failed before succeeding, also log:
+           ```markdown
+           ### Step N: [Title] — COMPLETED (after retry)
+           - Initial failure: [what went wrong]
+           - Root cause: [why it failed]
+           - Fix: [what was done to resolve it]
+           - Completed at: YYYY-MM-DD HH:MM
+           ```
+         - This creates institutional memory for future agents
+
+      vi. **Move to next step** only after current step is fully verified and progress is saved
+
+   e. **Full verification after all steps of this plan complete:**
+
+      Run EVERY applicable verification from the plan's Verification Plan section:
+
+      - **Tests:** Run the full test suite (unit, integration, e2e — whatever exists). All must pass.
+      - **Lint/Format:** Run linter and formatter. Zero errors.
+      - **Build:** Run the build command. Must succeed.
+      - **Browser testing:** If frontend changes, use playwright or chrome MCP tools to verify rendering and behavior.
+      - **API testing:** If backend changes, test endpoints with curl/httpx against a running server.
+      - **Infrastructure:** If K8s/Terraform changes, run dry-run/plan commands.
+      - **Edge cases:** Test any edge cases listed in the Verification Plan.
+      - **Manual checks:** Execute any manual verification steps listed.
+
+      If ANY verification fails: diagnose, fix, re-verify. Do not skip failures.
+
+   f. **Update artifacts after completion of this plan:**
+      - Update `docs/context/` if the implementation changed the architecture or introduced new patterns
+      - Mark the plan file as completed:
+        - Change `_Status: IN PROGRESS_` to `_Status: COMPLETED_`
+        - Add completion date: `_Completed: YYYY-MM-DD_`
+        - Add summary: `_Summary: [1-2 sentence summary of what was done]_`
+      - Commit all remaining changes with conventional commit messages
+
+5. **Sequential plan handoff** (when moving to the next plan in a queue):
+   - Before starting the next plan, check what files the just-completed plan modified: `git diff --name-only HEAD~N` (where N = number of commits from that plan)
+   - If the next plan touches any of the same areas, refresh context:
+     - Re-read modified files to understand current state
+     - Update `docs/context/` if architecture changed
+   - Pass a brief "prior plan summary" to the next plan's execution context so subagents know what just changed
+
+6. **Continue until all pending plans are executed.** For parallel groups, wait for all plans in the group to complete before starting dependent plans.
+
+7. **After all plans are complete:** Invoke `superpowers:verification-before-completion` to confirm all claims. Then invoke `superpowers:finishing-a-development-branch` to handle branch completion (merge, PR, or cleanup).
+
+8. **Run `/retro`** — capture learnings from the entire execution:
+   - What worked, what didn't, what was surprising
+   - Auto-update CLAUDE.md, docs/context/, and MEMORY.md with learnings
+   - Write retro to `docs/retros/YYYY-MM-DD-<task-slug>.md`
+   - This closes the feedback loop so future agents benefit from this execution's experience
+
+9. **Report:** Summary of all plans executed, what was implemented in each, all verification results, retro highlights, and any issues encountered and resolved.
+
+### Critical Rules
+
+- **Never claim done without fresh verification output as evidence.**
+- **Never skip a failing test.** Diagnose and fix it.
+- **Never move to the next step with open issues.**
+- **If blocked on a step,** try alternative approaches before asking for help.
+- **One commit per logical change,** conventional commit format.