configs-all 1.0.0

package/claude/commands/push-sync.md

@@ -0,0 +1,82 @@
+## Commit, Push & Sync All Machines
+
+Commit and push local changes, then deploy configs to all machines (or specific ones) via SSH. Combines `/push` and `/sync` into one command.
+
+**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.
+
+### Input
+$ARGUMENTS - optional: space-separated machine names (e.g., "mikpc", "mikpc duplo"). If omitted, syncs to ALL configured machines.
+
+### Subagent prompt
+
+You are committing, pushing, and syncing the configs repo across machines. Target machines: $ARGUMENTS (if empty, sync to all).
+
+#### Phase 1: Commit & Push
+
+1. Run in parallel:
+   - `git status --short` to see all changes
+   - `git diff` and `git diff --staged` to see what changed
+   - `git log --oneline -5` to match commit message style
+   - `git branch --show-current` to get the current branch
+
+2. If there are changes to commit:
+   - Stage appropriate files (specific paths, not `git add -A`). Never stage secrets.
+   - Write a conventional commit message (feat:/fix:/chore:/refactor:/docs:/test:). Use a HEREDOC.
+   - Push to remote with `git push -u origin <branch>`
+
+3. If already clean and pushed, skip to Phase 2.
+
+#### Phase 2: Sync Machines
+
+**Machine registry** (verify with SSH before attempting):
+
+| Machine | SSH Host | Dropbox Path | Notes |
+|---------|----------|-------------|-------|
+| mikpc | `mikpc` | `~/Dropbox/mikpc/dev/configs` | WSL, NTFS quirks with mcp.json |
+| duplo | `duplo` | `~/Dropbox/duplo/dev/chiefmikey/configs` | Work Mac |
+| mikbook | `mikbook` | `~/Dropbox/mikbook/dev/configs` | MacBook |
+
+For each target machine (run sequentially — SSH sessions can't overlap safely):
+
+a. **Verify connectivity:** `ssh -o ConnectTimeout=5 -o BatchMode=yes <host> echo ok`
+   - If unreachable, log a warning and skip this machine. Don't fail the whole run.
+
+b. **Pull latest on the remote:**
+   ```bash
+   ssh <host> "cd <dropbox-path> && git pull --ff-only"
+   ```
+   - If pull fails, log the error and skip deploy. Don't force.
+
+c. **Deploy configs on the remote:**
+   ```bash
+   ssh <host> "cd <dropbox-path> && ./scripts/sync/push-configs.zsh"
+   ```
+
+d. **Record the deployed commit:**
+   ```bash
+   ssh <host> "cd <dropbox-path> && git log --oneline -1"
+   ```
+
+e. **Verify critical paths:**
+   ```bash
+   ssh <host> "git config user.email && echo 'git: ok'"
+   ssh <host> "command -v zsh && echo 'zsh: ok'"
+   ```
+
+#### Report
+
+```
+## Push & Sync Report
+Local commit: abc1234 feat: latest change
+Push: origin/main ✓
+
+| Machine | Status | Commit | Details |
+|---------|--------|--------|---------|
+| mikpc | synced | abc1234 | push-configs: ok (3 warnings) |
+| duplo | synced | abc1234 | push-configs: ok |
+| mikbook | skipped | — | unreachable (connection timed out) |
+
+**Successfully synced:** 2/3 machines
+**Skipped:** mikbook (unreachable)
+**Warnings:** [any warnings from push-configs on synced machines]
+```

package/claude/commands/push.md

@@ -0,0 +1,34 @@
+## Commit & Push Changes
+
+**IMPORTANT: Immediately delegate this entire task to a subagent using the Agent tool with `model: "haiku"` and `subagent_type: "general-purpose"`.** Do not perform any git operations yourself. Pass the full prompt below to the subagent and relay its result.
+
+### Subagent prompt
+
+You are committing and pushing code changes. Follow these steps exactly:
+
+1. Run in parallel:
+   - `git status --short` to see all changes
+   - `git diff` and `git diff --staged` to see what changed
+   - `git log --oneline -5` to match commit message style
+   - `git branch --show-current` to get the current branch
+
+2. Review the changes:
+   - Never stage files that look like secrets (.env, credentials, tokens, keys)
+   - If there are no changes to commit, say so and stop
+
+3. Stage the appropriate files:
+   - If all changes are related, stage them all with specific file paths (not `git add -A`)
+   - If changes span unrelated concerns, stage only the coherent set and note what was left out
+
+4. Write a conventional commit message:
+   - Use the project's commit style from git log (feat:, fix:, chore:, refactor:, docs:, test:)
+   - Summarize the "why" not the "what" — 1-2 sentences max
+   - Use a HEREDOC: `git commit -m "$(cat <<'EOF' ... EOF)"`
+
+5. Push to remote:
+   - Use `git push -u origin <branch>` to ensure tracking is set
+   - Never force push
+
+6. Run `git status` after pushing to confirm success
+
+7. Report: what was committed, the commit hash, the remote URL, and whether any changes remain unstaged

package/claude/commands/research.md

@@ -0,0 +1,73 @@
+## Deep Codebase Research
+
+Produce a persistent research artifact before planning or implementing. This is pure understanding — no proposals, no plans, no code changes.
+
+**Do NOT delegate this command to a subagent.** This is an orchestration command — Opus runs it directly.
+
+### Input
+$ARGUMENTS - area to investigate (e.g., "authentication flow", "src/api/", "how billing integrates with Stripe")
+
+### Instructions
+
+1. **Identify scope** from the argument. If vague, infer the most useful investigation area from context. Don't ask — start reading.
+
+2. **Read existing documentation first:**
+   - Check `docs/research/` for existing research on this area — read it before exploring
+   - Check `docs/context/` for repo context snapshots
+   - Read project CLAUDE.md if it exists
+   - This prevents redundant exploration and builds on prior understanding
+
+3. **Read deeply, not broadly.** Follow the actual logic:
+   - Trace data flow end-to-end (entry point → transformations → storage/output)
+   - Read function bodies, not just signatures
+   - Follow imports to understand real dependencies
+   - Check tests to understand intended behavior and edge cases
+   - Look at recent git history on key files for context on why things are the way they are
+
+   Use parallel Explore subagents to cover independent areas of the codebase simultaneously.
+
+4. **Verify ALL findings against actual code — this is non-negotiable.** The value of research docs depends on accuracy.
+   - Check git log since any existing research doc's date — have relevant files changed?
+   - Read actual source files to confirm architectural claims, don't copy from existing docs without verifying
+   - If an existing research doc covers this area and is still accurate, update it rather than creating a duplicate
+   - If an existing doc is stale, update it immediately with current findings
+
+5. **Write findings** to `docs/research/YYYY-MM-DD-<topic>.md`:
+
+   ```markdown
+   # Research: <Topic>
+   _Date: YYYY-MM-DD_
+
+   ## Overview
+   What this area does in 2-3 sentences.
+
+   ## Architecture
+   How the pieces fit together. Key files and their roles.
+
+   ## Data Flow
+   How data moves through the system, step by step.
+
+   ## Patterns & Conventions
+   What conventions this code follows. How it differs from the rest of the codebase (if it does).
+
+   ## Dependencies
+   What it depends on (internal + external). What depends on it.
+
+   ## Gotchas
+   Non-obvious behavior, tech debt, fragile areas, implicit assumptions.
+
+   ## Open Questions
+   Things that weren't clear from reading alone.
+   ```
+
+   Omit sections that don't apply. Add sections if the area warrants it.
+
+6. **Do NOT:**
+   - Propose changes or improvements
+   - Write a plan
+   - Suggest refactors
+   - Fix anything
+
+   The only output is understanding, written down.
+
+7. Report the file path and a brief summary when done. If Open Questions exist, highlight them — the user may want to direct a deeper pass.

package/claude/commands/retro.md

@@ -0,0 +1,95 @@
+## Post-Task Retrospective
+
+Capture learnings after completing a task — what worked, what didn't, what was surprising. Automatically updates CLAUDE.md, MEMORY.md, and relevant docs so the system gets smarter after every task.
+
+**Do NOT delegate this command to a subagent.** This is an orchestration command — Opus runs it directly.
+
+### Input
+$ARGUMENTS - optional description of the task that was just completed. If omitted, infers from recent git history and docs/plans/.
+
+### Instructions
+
+1. **Identify what was just completed:**
+   - If `$ARGUMENTS` describes the task, use that
+   - Otherwise: check `docs/plans/` for recently completed plans (`_Status: COMPLETED_`)
+   - Check `docs/spikes/` for recently completed spikes
+   - Check `docs/incidents/` for recently resolved incidents
+   - Check `git log --oneline -20` for recent commit patterns
+   - Check `docs/handoff/` for recent session context
+
+2. **Analyze the work:**
+   - Read the completed plan's Execution Journal (if it exists) for failure/retry history
+   - Read the git diff between the start and end of the work
+   - Check: did the plan's steps match reality? Were there deviations?
+   - Check: were there unexpected blockers or surprises?
+   - Check: did any tools/commands fail or need workarounds?
+
+3. **Extract learnings in these categories:**
+
+   **What worked well:**
+   - Patterns, approaches, or tools that were effective
+   - Decisions that proved correct
+
+   **What didn't work:**
+   - Approaches that failed and why
+   - Time wasted on dead ends
+   - Commands or tools that didn't behave as expected
+
+   **What was surprising:**
+   - Non-obvious behavior discovered
+   - Gotchas encountered
+   - Assumptions that turned out wrong
+
+   **Process improvements:**
+   - Should a slash command be updated based on this experience?
+   - Should a CLAUDE.md convention be added or changed?
+   - Should a new gotcha be documented?
+
+4. **Apply learnings automatically:**
+
+   a. **Update project CLAUDE.md** if learnings revealed:
+      - New conventions that should be followed
+      - New "Common Mistakes to Avoid" entries
+      - Incorrect or outdated instructions
+
+   b. **Update `docs/context/`** if learnings revealed:
+      - New architectural patterns introduced
+      - New gotchas or fragile areas
+      - Changed development workflow
+
+   c. **Update MEMORY.md** (if accessible) if learnings revealed:
+      - New cross-project patterns or preferences
+      - Tool-specific insights that apply everywhere
+      - Machine-specific quirks discovered
+
+   d. **Suggest command updates** if:
+      - A slash command didn't cover a gap encountered during work
+      - A slash command's instructions didn't match reality
+      - Format: "The `/command-name` command should be updated: [specific change]"
+
+5. **Write the retro** to `docs/retros/YYYY-MM-DD-<task-slug>.md`:
+
+   ```markdown
+   # Retro: <Task>
+   _Date: YYYY-MM-DD_
+   _Plan: docs/plans/<file>.md (if applicable)_
+
+   ## Summary
+   What was done in 1-2 sentences.
+
+   ## What Worked
+   - [Effective patterns, good decisions]
+
+   ## What Didn't Work
+   - [Failed approaches, time sinks, dead ends]
+
+   ## Surprises
+   - [Non-obvious findings, broken assumptions]
+
+   ## Applied Updates
+   - [x] Updated CLAUDE.md: [what was changed]
+   - [x] Updated docs/context/: [what was changed]
+   - [ ] Suggested: update `/command-name` to [change]
+   ```
+
+6. Report the retro file path, what was updated, and any suggested command changes.

package/claude/commands/review-pr.md

@@ -0,0 +1,96 @@
+## Review External PR — Full Context-Aware PR Review
+
+Review someone else's pull request with full project context. Loads architecture, conventions, and gotchas so the review is against this project's actual standards — not generic best practices. Posts review comments directly via `gh`.
+
+Different from `/review` (which reviews your own uncommitted changes) — this reviews an existing PR from a teammate or contributor.
+
+### Input
+$ARGUMENTS - PR number, URL, or branch name (e.g., "123", "https://github.com/org/repo/pull/123", "feat/auth-refactor")
+
+### Instructions
+
+**Before delegating, gather project context:**
+1. Read `docs/context/` for the most recent context snapshot — extract Architecture, Conventions, Testing, and Gotchas sections
+2. Read the project CLAUDE.md if it exists — extract Conventions and Common Mistakes sections
+3. Read `docs/incidents/` for recent incidents — are any related to the files being changed?
+4. Read `docs/spikes/` for recent spikes — is this PR implementing a spiked approach?
+
+**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.
+
+### Subagent prompt
+
+You are a thorough, context-aware code reviewer. Review PR `$ARGUMENTS` against this project's actual standards and patterns.
+
+**Project Context:**
+[Inject Architecture, Conventions, Testing, Gotchas from docs/context if available]
+[Inject Conventions, Common Mistakes from project CLAUDE.md if available]
+[Inject any related incidents or spikes if relevant]
+If no project context is available, review against general best practices and note that project context was unavailable.
+
+1. **Fetch PR details:**
+   ```bash
+   gh pr view $ARGUMENTS --json title,body,author,baseRefName,headRefName,files,additions,deletions,commits
+   gh pr diff $ARGUMENTS
+   ```
+
+2. **Understand the PR:**
+   - What is the goal? (Read the PR description and commit messages)
+   - What files are changed? (Group by area: frontend, backend, infra, config, tests)
+   - What is the blast radius? (How many files, how central are they?)
+   - Does this PR implement a spiked approach? (Check spike context if provided)
+
+3. **Read the changed files** in their full context — don't just look at the diff. Understand how the changes fit into the broader codebase:
+   - Read each modified file in full (not just the changed lines)
+   - Check how changed functions/classes are used elsewhere
+   - Check if tests exist for the changed code
+
+4. **Review every change for:**
+   - **Correctness:** Logic errors, off-by-one, null/undefined handling, race conditions
+   - **Security:** Hardcoded secrets, injection vulnerabilities, XSS, exposed credentials, OWASP top 10
+   - **Types:** Missing types, incorrect types, unsafe `any` usage (TypeScript)
+   - **Error handling:** Unhandled promise rejections, missing try/catch, bare exceptions
+   - **Project conventions:** Does the code follow the patterns established in this codebase? (Use the project context above)
+   - **Testing:** Are new features tested? Are edge cases covered? Do existing tests still apply?
+   - **K8s specific:** Missing resource limits, hardcoded values, missing labels
+   - **Python specific:** Type hints, structured logging, idempotency
+   - **Performance:** N+1 queries, unnecessary re-renders, missing indexes, unbounded loops
+   - **Breaking changes:** API contract changes, migration needs, backwards compatibility
+
+5. **Check for anti-patterns:**
+   - Files that shouldn't be committed (`.env`, `node_modules`, build artifacts, `.pyc`)
+   - Overly large PR that should be split
+   - Missing or inadequate PR description
+   - Tests that test implementation instead of behavior
+   - Copied code that should be abstracted (only if 3+ occurrences)
+
+6. **Determine verdict:**
+   - **Approve** — changes are solid, no issues or only minor nits
+   - **Request Changes** — blocking issues that must be fixed before merge
+   - **Comment** — non-blocking feedback, questions, or suggestions
+
+7. **Post the review:**
+   ```bash
+   gh pr review $ARGUMENTS --approve --body "review body"
+   # or
+   gh pr review $ARGUMENTS --request-changes --body "review body"
+   # or
+   gh pr review $ARGUMENTS --comment --body "review body"
+   ```
+
+   Review body format:
+   ```markdown
+   ## Review Summary
+   [1-2 sentences: what this PR does and overall assessment]
+
+   ## Issues (if any)
+   ### Blocking
+   - **file:line** — description of issue and suggested fix
+
+   ### Non-blocking
+   - **file:line** — suggestion or question
+
+   ## What looks good
+   - [Specific callouts of good decisions or clean code]
+   ```
+
+8. **Report back** with: verdict, issue count (blocking/non-blocking), and key observations.

package/claude/commands/review.md

@@ -0,0 +1,41 @@
+## Self Code Review
+
+### Input
+$ARGUMENTS - optional: specific files or areas to focus the review on. If omitted, reviews all uncommitted changes.
+
+**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, Conventions, and Gotchas sections
+2. Read the project CLAUDE.md if it exists — extract Conventions and Common Mistakes sections
+3. 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.
+
+### Subagent prompt
+
+You are a strict senior code reviewer. Review all current changes before committing.
+
+**Project Context:**
+[Inject Architecture, Conventions, Gotchas from docs/context if available]
+[Inject Conventions, Common Mistakes from project CLAUDE.md if available]
+If no project context is available, review against general best practices.
+
+1. Run in parallel:
+   - `git diff` to see all unstaged changes
+   - `git diff --cached` for staged changes
+
+2. Review every change for:
+   - **Correctness:** Logic errors, off-by-one, null/undefined handling, race conditions
+   - **Security:** Hardcoded secrets, SQL/NoSQL injection, XSS, exposed credentials
+   - **Types:** Missing types, incorrect types, unsafe `any` usage (TypeScript)
+   - **Error handling:** Unhandled promise rejections, missing try/catch, bare exceptions
+   - **Project conventions:** Does the code follow the patterns established in this codebase? (Use the project context above)
+   - **K8s specific:** Missing resource limits, hardcoded values that should be configurable, missing labels
+   - **Python agents:** Idempotency, graceful error handling, structured logging
+
+3. Check for accidental files: `.env`, `node_modules`, `__pycache__`, `.pyc`, build artifacts
+
+4. Provide a clear verdict:
+   - **Ship it** — changes look good
+   - **Needs fixes** — list specific issues with file:line references
+
+5. If "Needs fixes", describe each fix precisely so the caller can apply them.

package/claude/commands/scaffold-agent.md

@@ -0,0 +1,45 @@
+## Python Agent Scaffold
+
+**IMPORTANT: Immediately delegate this entire task to a subagent using the Agent tool with `model: "sonnet"` and `subagent_type: "general-purpose"`.** Do not create any files yourself. Pass the full prompt below to the subagent and relay its result.
+
+### Input
+$ARGUMENTS - what the agent should do (e.g., "monitor API health and alert", "sync data between services")
+
+### Subagent prompt
+
+You are scaffolding a Python automation agent. Purpose: $ARGUMENTS
+
+1. Determine if this is a new agent or modification to existing.
+
+2. For new agents, create the following structure:
+   ```
+   agent_name/
+   ├── __init__.py
+   ├── agent.py          # Main agent logic
+   ├── config.py         # Pydantic settings/config
+   ├── models.py         # Data models
+   ├── requirements.txt  # Dependencies
+   ├── Dockerfile        # Multi-stage build
+   └── tests/
+       ├── __init__.py
+       └── test_agent.py
+   ```
+
+3. Agent must follow these patterns:
+   - Pydantic BaseModel for all config and data structures
+   - `logging` module with structured JSON logging
+   - Idempotent operations (safe to run multiple times)
+   - Graceful error handling with retries for transient failures
+   - Health check endpoint if long-running
+   - Environment variables for all configuration (never hardcoded)
+   - Type hints on all function signatures
+   - `pathlib.Path` over `os.path`
+
+4. If deploying to K8s, generate deployment manifest with:
+   - Resource requests/limits
+   - ConfigMap for non-sensitive config
+   - Secret references for sensitive data
+   - Proper labels: app, env, version, managed-by
+   - Liveness/readiness probes if applicable
+
+5. Run `pytest` to verify tests pass.

package/claude/commands/setup.md

@@ -0,0 +1,92 @@
+## Initialize Project CLAUDE.md
+
+Generate or validate a project-specific CLAUDE.md tailored to the current codebase.
+
+When run in a repo that already has a CLAUDE.md, validates it against the current state of the codebase and fortifies it — fixing stale information, adding missing sections, and strengthening weak areas. Does NOT overwrite or start from scratch.
+
+### Input
+$ARGUMENTS - optional: brief description of the project's purpose
+
+### Steps
+
+1. **Check for existing CLAUDE.md.** If one exists, read it fully — this is a validation/fortification run, not a fresh generation.
+
+2. **Detect the tech stack** by scanning for key files. Run these checks in parallel:
+   - `package.json` / `tsconfig.json` / `angular.json` / `next.config.*` / `vite.config.*` → JS/TS project
+   - `pyproject.toml` / `setup.py` / `requirements.txt` / `Pipfile` → Python project
+   - `Chart.yaml` / `helmfile.yaml` / `k8s/` / `manifests/` / `terraform/` → Infrastructure
+   - `Dockerfile` / `docker-compose.yml` → Containerized
+   - `.github/workflows/` / `.gitlab-ci.yml` → CI/CD
+   - `Makefile` / `Justfile` / `Taskfile.yml` → Task runner
+   - `.eslintrc*` / `prettier.config*` / `ruff.toml` / `pyproject.toml [tool.ruff]` → Linting/formatting
+   - `jest.config*` / `vitest.config*` / `cypress.config*` / `playwright.config*` / `pytest.ini` / `conftest.py` → Testing
+   - `go.mod` → Go project
+   - `Cargo.toml` → Rust project
+
+3. **Analyze the project structure:**
+   - Read the top-level directory listing
+   - Read `package.json` scripts (if exists) to extract commands
+   - Read `pyproject.toml` scripts/tool config (if exists)
+   - Read `Makefile` / `Justfile` targets (if exists)
+   - Identify the main source directories (`src/`, `app/`, `lib/`, `cmd/`, etc.)
+   - Check for monorepo patterns (`packages/`, `apps/`, `workspace`)
+
+4. **Check for existing conventions:**
+   - Read a few representative source files to detect coding patterns (imports, error handling, naming)
+   - Check git log for commit message conventions: `git log --oneline -20`
+   - Look for existing docs: `README.md`, `CONTRIBUTING.md`, `docs/`
+   - Check for existing `.env.example` to understand config patterns
+
+5. **If CLAUDE.md already exists — validate and fortify:**
+   - Compare each section against current codebase reality
+   - Fix any stale information (outdated commands, wrong directory structure, missing tech stack entries)
+   - Add missing sections that should exist based on what you detected
+   - Strengthen weak sections (e.g., "Common Mistakes" that are too generic)
+   - Do NOT remove user-added content or customizations — preserve intent
+   - Do NOT rewrite sections that are already accurate
+   - Report what was changed and why
+
+6. **If no CLAUDE.md exists — generate fresh** with these sections, filled in with real values from the codebase (never leave placeholders or HTML comments):
+
+   ```markdown
+   # Project CLAUDE.md - [Project Name]
+
+   ## Project Overview
+   [1-2 sentences: what this does, derived from README/package.json description or $ARGUMENTS]
+
+   ## Tech Stack
+   [Actual frameworks, languages, and tools detected — not template defaults]
+
+   ## Architecture
+   [Real directory tree from `ls`, showing only important directories with brief descriptions]
+
+   ## Commands
+   [Actual commands from package.json scripts, Makefile targets, or pyproject.toml — not guessed defaults]
+
+   ## Conventions
+   [Real patterns observed in the code, not generic best practices. Examples:
+   - Import ordering style actually used
+   - State management pattern actually used
+   - Error handling pattern actually used
+   - Naming conventions actually used (camelCase, snake_case, etc.)
+   - Any patterns from CONTRIBUTING.md or existing docs]
+
+   ## Common Mistakes to Avoid
+   [Project-specific pitfalls based on the tech stack and patterns observed.
+   Start with 2-3 items. More will be added as Claude works in this project.]
+
+   ## Testing
+   [How to run tests, what framework is used, any special setup needed]
+   ```
+
+7. **Write the file** to `./CLAUDE.md` in the project root.
+
+8. **Verify** the file was created/updated and show a summary of what was detected or changed.
+
+### Rules
+- Fill in ALL sections with real data from the codebase. Never leave `<!-- comments -->` or placeholder text.
+- If a section doesn't apply (e.g., no database), omit it entirely rather than leaving it empty.
+- Keep it concise — under 80 lines. This is a reference card, not documentation.
+- Don't duplicate instructions from the global `~/CLAUDE.md`. Only include project-specific details.
+- For monorepos, note the workspace structure and key packages.
+- On rerun: preserve user intent, fix facts, add missing context. Never destructively rewrite.

package/claude/commands/ship-prod.md

@@ -0,0 +1,97 @@
+## Ship to Production
+
+Full production deployment pipeline — self-review PR, merge to main, deploy to production, and monitor until healthy. This is the highest-stakes command. Every step is verified. Does not stop until production is confirmed healthy.
+
+**WARNING:** This command merges to main and deploys to production. It will self-review the PR and only merge when 100% confident.
+
+**Do NOT delegate this command to a subagent.** This is an orchestration command — Opus runs it directly.
+
+### Input
+$ARGUMENTS - optional PR number or URL. If omitted, finds the most recent open PR for the current branch.
+
+### Instructions
+
+1. **Gather deployment context:**
+   - Read project CLAUDE.md and `docs/context/` for production deployment workflow
+   - Detect deployment method (same detection as `/ship`)
+   - Identify the production environment and any production-specific configuration
+   - Check for required approvals, branch protection rules, or deployment gates
+
+2. **Load the PR:**
+   - If `$ARGUMENTS` has a PR number/URL, use it
+   - Otherwise: `gh pr list --head $(git branch --show-current)` to find the PR
+   - If no PR exists, stop — "Run `/ship` first to create a PR and deploy to dev"
+
+3. **Pre-merge verification** (run in parallel):
+   - `gh pr checks` — ALL CI checks must be passing
+   - `gh pr view --json reviews` — check for existing reviews
+   - Read the full diff: `gh pr diff`
+   - Run the full test suite locally — ALL must pass
+   - Run linter — zero errors
+   - Run build — must succeed
+
+4. **Self-review the PR** with production mindset:
+   - Read every line of the diff
+   - Check for:
+     - **Security:** No secrets, no injection vectors, no exposed endpoints
+     - **Data safety:** No destructive migrations, no data loss risks
+     - **Backwards compatibility:** API contracts, database schemas, config changes
+     - **Error handling:** All failure modes covered, graceful degradation
+     - **Performance:** No N+1 queries, no unbounded operations, no memory leaks
+     - **Rollback plan:** Can this be reverted safely if something goes wrong?
+   - Check that the dev deployment (from `/ship`) has been running without issues
+
+5. **Confidence gate:**
+   - If ANY concern exists: stop and report the concern. Do NOT merge.
+   - Only proceed if 100% confident this is production-ready.
+   - Document the confidence assessment: what was checked, what gives confidence.
+
+6. **Merge the PR:**
+   - `gh pr merge --merge` (preserve full git history, never squash)
+   - Verify the merge succeeded: `gh pr view --json state`
+
+7. **Deploy to production:**
+   - **If CI/CD auto-deploys on merge to main:** Monitor the deployment pipeline:
+     - Poll `gh run list --branch main` until the production deploy workflow completes
+     - If deploy fails, read logs with `gh run view --log-failed`
+   - **If manual dispatch:** `gh workflow run <prod-deploy-workflow> --ref main`
+   - **If K8s:** `kubectl apply` to production context, watch rollout status
+   - **If ECS:** Monitor service update, wait for healthy running count
+   - **If Docker Compose on remote:** SSH to prod, pull, `docker compose up -d`
+
+8. **Post-deploy production monitoring:**
+   - **Tail production logs** for 60-120 seconds:
+     - K8s: `kubectl logs -f deployment/<name> --tail=100 --timeout=120s -n production`
+     - ECS: `aws logs tail <prod-log-group> --since 5m --follow`
+   - **Health checks:** Hit production health endpoints
+   - **Error scanning:** Look for ERROR, FATAL, panic, unhandled, exception
+   - **Metrics check:** If monitoring tools are available (CloudWatch, Datadog, etc.), check error rate and latency
+   - **Compare to baseline:** Are error rates higher than pre-deploy? Is latency increased?
+
+9. **If production issues detected:**
+   - **Severity assessment:** Is this a rollback-worthy issue or a quick fix?
+   - If rollback needed: Report immediately — "Production issue detected. Recommend rollback: `git revert <commit> && git push`"
+   - If quick fix: Fix, push to new branch, go through `/ship` again (do NOT ship-prod again without dev verification)
+
+10. **Report:**
+    ```
+    ## Production Ship Report
+    - **PR:** <URL>
+    - **Merged to:** main
+    - **Merge method:** merge (full history)
+    - **Deployed to:** production
+    - **Deployment method:** <method>
+    - **Self-review:** Passed (no concerns)
+    - **Health check:** passing
+    - **Logs:** clean (monitored for N seconds)
+    - **Error rate:** normal / elevated
+    - **Status:** Production healthy and verified
+    ```
+
+### Critical Rules
+
+- **NEVER merge with failing CI checks.**
+- **NEVER skip the self-review.** Read every line.
+- **NEVER proceed past the confidence gate with concerns.**
+- **NEVER ignore elevated error rates post-deploy.**
+- **If in doubt, stop and report.** A delayed deploy is always better than a broken production.