configs-all 1.0.0

package/claude/commands/guard.md

@@ -0,0 +1,102 @@
+## Security & Quality Audit
+
+Proactive security and code quality audit of a specific area or the full codebase. Produces a persistent audit artifact that future `/prep`, `/review`, and `/review-pr` agents can reference for known vulnerabilities and security posture.
+
+### Input
+$ARGUMENTS - optional: scope to audit (directory path, file path, or area like "authentication", "API endpoints", "dependencies"). If omitted, audits the full codebase.
+
+### Instructions
+
+**Before delegating, gather project context:**
+1. Read `docs/context/` for the most recent context snapshot — understand the architecture
+2. Read the project CLAUDE.md if it exists — understand conventions
+3. Read `docs/research/` for any prior audits (`*audit*`, `*security*`) — don't duplicate findings
+4. Read `docs/incidents/` — have there been security-related incidents before?
+
+**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 security-focused code auditor. Audit the scope: `$ARGUMENTS` (or full codebase if empty).
+
+**Project Context:**
+[Inject Architecture, Tech Stack, Conventions from docs/context if available]
+[Inject any prior audit findings from docs/research if available]
+[Inject any security-related incidents from docs/incidents if available]
+
+1. **Determine audit scope:**
+   - If a specific path/area was given, focus there but note cross-cutting concerns
+   - If full codebase, prioritize: auth → API boundaries → data handling → dependencies → config → infrastructure
+
+2. **OWASP Top 10 scan** (check each against actual code):
+   - **Injection:** SQL/NoSQL injection, command injection, LDAP injection, template injection
+   - **Broken Auth:** Hardcoded credentials, weak session management, missing MFA references
+   - **Sensitive Data:** Secrets in code, unencrypted storage, excessive logging of PII
+   - **XXE:** XML parsing without entity restrictions
+   - **Broken Access Control:** Missing authorization checks, IDOR, path traversal
+   - **Misconfig:** Debug mode in production, default credentials, overly permissive CORS
+   - **XSS:** Unsanitized user input in templates/responses
+   - **Insecure Deserialization:** Untrusted data deserialization
+   - **Known Vulnerabilities:** Outdated dependencies with CVEs
+   - **Insufficient Logging:** Missing audit trails for sensitive operations
+
+3. **Dependency audit:**
+   - If `package.json` exists: run `npm audit` (or check `package-lock.json` for known CVEs)
+   - If `requirements.txt`/`pyproject.toml` exists: check for known vulnerable versions
+   - If `go.mod` exists: check for vulnerable modules
+   - Flag any dependencies that are severely outdated (2+ major versions behind)
+
+4. **Secret scanning:**
+   - Search for patterns: API keys, tokens, passwords, connection strings, private keys
+   - Check `.env` files, config files, hardcoded strings
+   - Verify `.gitignore` covers sensitive files
+   - Check git history for accidentally committed secrets: `git log --diff-filter=D --name-only -- '*.env' '*.key' '*.pem'`
+
+5. **Infrastructure audit** (if applicable):
+   - K8s manifests: resource limits, security contexts, network policies, RBAC
+   - Dockerfiles: running as root, unnecessary packages, secrets in layers
+   - Terraform: overly permissive IAM, public S3 buckets, unencrypted resources
+   - CI/CD: secrets in plaintext, missing branch protections
+
+6. **Code quality signals** (security-adjacent):
+   - Error handling that leaks internal details to users
+   - Missing input validation at system boundaries
+   - Race conditions in concurrent code
+   - Unsafe type assertions or casts
+   - Missing rate limiting on public endpoints
+
+7. **Write findings** to `docs/research/YYYY-MM-DD-audit-<scope-slug>.md`:
+
+   ```markdown
+   # Security Audit: <Scope>
+   _Date: YYYY-MM-DD_
+   _Scope: <what was audited>_
+   _Severity Summary: X critical, Y high, Z medium, W low_
+
+   ## Critical Findings
+   ### Finding 1: [Title]
+   - **Severity:** Critical/High/Medium/Low
+   - **Location:** file:line
+   - **Description:** What the vulnerability is
+   - **Impact:** What could happen if exploited
+   - **Recommendation:** How to fix it
+   - **Evidence:** Code snippet or command output
+
+   ## Dependency Status
+   | Package | Current | Latest | CVEs | Action Needed |
+   |---------|---------|--------|------|---------------|
+
+   ## Secret Scan Results
+   - [Results of secret scanning]
+
+   ## Infrastructure Findings
+   - [If applicable]
+
+   ## Positive Observations
+   - [What's already done well — important for maintaining good practices]
+
+   ## Recommended Actions
+   Priority-ordered list of what to fix and in what order.
+   ```
+
+8. **Report back** with: total findings by severity, critical items requiring immediate action, and the audit file path.

package/claude/commands/handoff.md

@@ -0,0 +1,66 @@
+## Session Handoff
+
+Capture current session state so the next Claude session picks up seamlessly without re-explanation. Run this before ending a session or switching contexts.
+
+**Do NOT delegate this command to a subagent.** This is an orchestration command — Opus runs it directly.
+
+### Input
+$ARGUMENTS - optional notes about what to highlight or context to preserve. If omitted, auto-detects from git state, open tasks, and recent changes.
+
+### Instructions
+
+1. **Gather current state** by running these checks in parallel:
+   - `git status` — uncommitted changes and their files
+   - `git diff --stat` — scope of uncommitted work
+   - `git log --oneline -10` — recent commits this session
+   - `git branch --show-current` — current branch
+   - Check `docs/plans/` for any `_Status: IN PROGRESS_` plans
+   - Check `docs/spikes/` for any `_Status: IN PROGRESS_` spikes
+   - Check `docs/incidents/` for any `_Status: ACTIVE_` or `_Status: MITIGATED_` incidents
+   - Check `docs/handoff/` for prior handoff docs (understand continuity)
+   - Read project CLAUDE.md for project context
+
+2. **Analyze the session:**
+   - What was the user working on? (Infer from commits, changes, and $ARGUMENTS)
+   - What decisions were made? (Check docs/plans/ for new or updated plans, recent commits)
+   - What's incomplete? (Uncommitted changes, IN PROGRESS plans, IN PROGRESS spikes, partially done steps)
+   - What's blocked? (Failed tests, unresolved issues, pending external dependencies)
+   - Are there active incidents? (ACTIVE or MITIGATED — flag these prominently)
+
+3. **Write the handoff** to `docs/handoff/YYYY-MM-DD.md` (if one already exists for today, use `YYYY-MM-DD-HHMMSS.md`):
+
+   ```markdown
+   # Session Handoff
+   _Date: YYYY-MM-DD_
+   _Branch: <current branch>_
+   _Machine: <hostname>_
+
+   ## What Was Done
+   Brief summary of work completed this session. Reference commits.
+
+   ## Current State
+   - Uncommitted changes and their purpose
+   - In-progress plans and which step they're on
+   - Build/test status (passing? known failures?)
+
+   ## Decisions Made
+   Key decisions from this session that the next session needs to know.
+
+   ## Blockers & Open Questions
+   Anything unresolved that needs attention.
+
+   ## What's Next
+   Prioritized list of remaining work, most important first.
+
+   ## Context That Would Be Lost
+   Anything non-obvious that the next session needs to understand —
+   workarounds applied, why a certain approach was chosen, things
+   that were tried and didn't work.
+   ```
+
+4. **If $ARGUMENTS provided,** incorporate the user's notes into the relevant sections.
+
+5. Report the file path and a brief summary of the handoff state.
+
+### Integration
+All doc-consuming commands (`/prep`, `/go`, `/plans`, `/init`, etc.) should check `docs/handoff/` for the most recent entry when starting a new session.

package/claude/commands/incident.md

@@ -0,0 +1,144 @@
+## Incident Response — Structured Production Fire Management
+
+When production is broken, follow this structured incident workflow. Prioritizes mitigation first, then root cause, then fix, then postmortem. Produces a persistent incident artifact so agents can resume if interrupted and future agents learn from past incidents.
+
+Different from `/triage` (which routes to the right command) — this IS the command when something is actively broken.
+
+**Do NOT delegate this command to a subagent.** This is an orchestration command — Opus runs it directly.
+
+### Input
+$ARGUMENTS - optional: description of what's broken (error message, alert, user report). If omitted, check for ACTIVE or MITIGATED incidents to resume.
+
+### Instructions
+
+1. **Check for existing incidents:**
+   - If `$ARGUMENTS` is empty, scan `docs/incidents/` for `_Status: ACTIVE_` or `_Status: MITIGATED_` — resume the most recent one
+   - If no active incidents exist and no arguments given, tell the user "No active incidents found. Provide a description of what's broken."
+   - If resuming, read the incident doc and pick up from the current phase
+
+2. **Load context:**
+   - Read `docs/context/` for the most recent context snapshot — understand the architecture fast
+   - Read project CLAUDE.md if it exists
+   - Read `docs/incidents/` for related past incidents — has this happened before?
+   - Read `docs/research/` for any relevant deep dives on the affected area
+
+3. **Create the incident document** at `docs/incidents/YYYY-MM-DD-<incident-slug>.md`:
+
+   ```markdown
+   # Incident: <Brief Title>
+   _Status: ACTIVE_
+   _Reported: YYYY-MM-DD HH:MM_
+   _Severity: P1/P2/P3_
+   _Phase: Assessment_
+   _LastCompletedPhase: 0_
+
+   ## Report
+   What was reported. Error messages, symptoms, user impact.
+
+   ## Impact Assessment
+   _Phase 1_
+   - **Users affected:**
+   - **Services affected:**
+   - **Data at risk:**
+   - **Revenue/business impact:**
+
+   ## Timeline
+   | Time | Event |
+   |------|-------|
+   | HH:MM | Incident reported |
+
+   ## Mitigation
+   _Phase 2_
+   **Goal:** Stop the bleeding. Not a permanent fix — just reduce impact.
+   - **Action taken:**
+   - **Result:**
+   - **Verified by:**
+
+   ## Root Cause Analysis
+   _Phase 3_
+   **Immediate cause:**
+   **Contributing factors:**
+   **Evidence:**
+
+   ## Fix
+   _Phase 4_
+   **What was changed:**
+   **Files modified:**
+   **Verification:**
+
+   ## Postmortem
+   _Phase 5_
+   ### What happened
+   ### What went well
+   ### What went poorly
+   ### Action items
+   - [ ] Action 1 — preventive measure
+   - [ ] Action 2 — detection improvement
+   ### Lessons learned
+   ```
+
+4. **Phase 1 — Impact Assessment (DO THIS FAST):**
+   - Determine severity:
+     - **P1:** Service down, data loss, or security breach — drop everything
+     - **P2:** Degraded service, partial outage, or significant user impact
+     - **P3:** Minor issue, workaround exists, limited user impact
+   - Identify affected services, users, and data
+   - Add to Timeline
+   - Update `_Phase: Assessment_`, `_Severity: P[1-3]_`
+
+5. **Phase 2 — Mitigation (STOP THE BLEEDING):**
+   - Find the fastest way to reduce impact — this is NOT the permanent fix
+   - Options to consider (fastest first):
+     - Rollback to last known good state
+     - Feature flag / disable the broken feature
+     - Scale up / restart affected services
+     - Redirect traffic / enable maintenance mode
+     - Hotfix the immediate symptom
+   - Apply the mitigation
+   - Verify it worked — check logs, metrics, user reports
+   - Update Timeline and `_Status: MITIGATED_`, `_Phase: Mitigation_`, `_LastCompletedPhase: 2_`
+
+6. **Phase 3 — Root Cause Analysis:**
+   - Now that the fire is out, investigate properly
+   - Check logs, traces, metrics around the incident time
+   - Check recent deployments — `git log --oneline -20`, CI/CD history
+   - Check recent config changes
+   - Check external dependencies (API outages, DNS, cloud provider status)
+   - Identify the immediate cause AND contributing factors
+   - Document evidence (log snippets, metrics, git history)
+   - Update `_Phase: Root Cause_`, `_LastCompletedPhase: 3_`
+
+7. **Phase 4 — Fix:**
+   - Implement the permanent fix (not just the mitigation)
+   - Run full verification: tests, lint, build
+   - Verify the fix addresses the root cause, not just the symptom
+   - If the mitigation IS the fix, document why
+   - Update Timeline and `_Phase: Fix_`, `_LastCompletedPhase: 4_`
+
+8. **Phase 5 — Postmortem:**
+   - Fill in the Postmortem section honestly — no blame, focus on systems
+   - Identify action items:
+     - **Preventive:** How do we stop this from happening again?
+     - **Detective:** How do we catch this faster next time?
+     - **Corrective:** What else needs fixing as a result?
+   - Extract lessons learned
+   - **Feed back into the system:**
+     - Update `docs/context/` if architecture understanding changed
+     - Update project CLAUDE.md with "never do X again" rules if applicable
+     - Update MEMORY.md if this is a cross-project learning
+     - Create follow-up tasks/spikes for action items that need more work
+   - Update `_Status: RESOLVED_`, `_Phase: Postmortem_`, `_LastCompletedPhase: 5_`
+   - Add `_Resolved: YYYY-MM-DD HH:MM_`
+   - Add `_Duration: Xh Ym_` (from report to resolution)
+   - Add `_RootCause: one-line summary_`
+
+9. **Report:** Incident summary, severity, duration, root cause, fix applied, action items, and lessons learned.
+
+### Critical Rules
+
+- **Mitigate first, investigate second.** Never spend 30 minutes debugging while production is down if a rollback would fix it in 2 minutes.
+- **Update status faithfully.** If interrupted at any phase, the status and `_LastCompletedPhase_` tell the next agent exactly where to pick up.
+- **Evidence over speculation.** Root cause must be supported by logs, metrics, or code — not guesses.
+- **No blame.** Postmortems focus on systems and processes, not people.
+- **Check for past incidents.** If this happened before, reference the previous incident and explain why the prior fix didn't prevent recurrence.
+- **Action items are mandatory.** Every incident must produce at least one preventive and one detective action item.

package/claude/commands/init.md

@@ -0,0 +1,78 @@
+## Initialize Repository for Autonomous Work
+
+Fully prepare a repository for autonomous Claude sessions. Generates or validates the project CLAUDE.md, produces deep research, and builds a context snapshot — everything an agent needs to work effectively without re-exploration.
+
+This is `/prep` without the plan phase. Run this when onboarding to a new repo or refreshing a repo's documentation artifacts.
+
+**Do NOT delegate this command to a subagent.** This is an orchestration command — Opus runs it directly.
+
+### Input
+$ARGUMENTS - optional: brief description of the project's purpose or focus area for research
+
+### Instructions
+
+Execute these three phases in order, carrying all context forward between phases.
+
+#### Phase 1: Setup — Project CLAUDE.md
+
+1. **Check for existing CLAUDE.md** in the project root.
+
+2. **If one exists — validate and fortify:**
+   - Detect the current tech stack, project structure, commands, and conventions
+   - Compare each section of the existing CLAUDE.md against current codebase reality
+   - Fix 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 with real observations from the code
+   - Preserve user-added content and customizations — never destructively rewrite
+   - Report what was changed and why
+
+3. **If none exists — generate fresh:**
+   - Detect tech stack, project structure, commands, conventions, testing setup
+   - Write `./CLAUDE.md` with real values — no placeholders, no generic content
+   - Sections: Project Overview, Tech Stack, Architecture, Commands, Conventions, Common Mistakes, Testing
+   - Keep it under 80 lines. Don't duplicate global `~/CLAUDE.md` instructions.
+
+#### Phase 2: Research — Deep Codebase Understanding
+
+4. **Read existing documentation:**
+   - The CLAUDE.md you just created/validated
+   - ALL files in `docs/research/` if the directory exists
+   - ALL files in `docs/context/` if the directory exists
+   - MEMORY.md if accessible
+
+5. **Deep codebase exploration** using parallel Explore subagents:
+   - Trace data flow end-to-end for the primary use case
+   - 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 "why" context
+
+6. **Verify ALL findings against actual code — this is non-negotiable.** The value of this system depends on docs being accurate. Never trust documentation blindly. Check git log since each doc's date for relevant changes. Run actual commands to verify documented instructions still work. Every claim carried forward must be verified against current reality.
+
+7. **Write or update** `docs/research/YYYY-MM-DD-<topic>.md`:
+   - If an existing research doc covers this area and is still accurate, update it
+   - If no research exists or it's stale, create a new one
+   - Use the standard research format: Overview, Architecture, Data Flow, Patterns & Conventions, Dependencies, Gotchas, Open Questions
+
+#### Phase 3: Context — Repo Knowledge Snapshot
+
+8. **Build or update the context snapshot:**
+   - If `docs/context/` has an existing doc, read it and verify against current state
+   - Update stale sections, add new context discovered during research
+   - If no context doc exists, create one
+
+9. **Write or update** `docs/context/YYYY-MM-DD-<repo-name>.md`:
+   - Overview, Tech Stack, Project Structure, Architecture
+   - Development Workflow (exact build/test/lint/deploy commands)
+   - Testing infrastructure, Dependencies, Environment
+   - Recent Trajectory (last 20-30 commits), Gotchas
+
+#### Report
+
+10. **Output all file paths** and a summary:
+    - CLAUDE.md: created or what was validated/changed
+    - Research: what was learned or updated
+    - Context: what was captured or changed
+    - Open Questions: highlight anything unclear that may need a deeper `/research` pass
+
+The repo is now fully prepared for autonomous work. Future sessions will read these artifacts first, saving significant context and tokens.

package/claude/commands/k8s-debug.md

@@ -0,0 +1,31 @@
+## Kubernetes Debug
+
+**IMPORTANT: Immediately delegate this entire task to a subagent using the Agent tool with `model: "sonnet"` 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 - description of the issue or resource to debug (e.g., "pods crashing in staging", "configmap not updating", "deployment stuck")
+
+### Subagent prompt
+
+You are debugging a Kubernetes issue. The issue is: $ARGUMENTS
+
+1. Identify the namespace context from the description.
+
+2. Run diagnostic commands in parallel:
+   - `kubectl get pods -n <namespace>` to check pod status
+   - `kubectl get events -n <namespace> --sort-by='.lastTimestamp'` for recent events
+   - `kubectl describe` on the problematic resource
+
+3. If pods are crashing:
+   - `kubectl logs <pod> -n <namespace> --tail=100` for current logs
+   - `kubectl logs <pod> -n <namespace> --previous --tail=100` for crash logs
+
+4. If deployment issues:
+   - `kubectl rollout status deployment/<name> -n <namespace>`
+   - Check resource limits, image pull errors, or config issues
+
+5. If ConfigMap/Secret issues:
+   - Verify the resource exists and has expected keys
+   - Check if pods referencing it have been restarted since last update
+
+6. Provide a clear diagnosis with root cause. Suggest a fix and validate it with `--dry-run=client` first. Only suggest and validate fixes — do NOT apply them. Report back and let the user decide.

package/claude/commands/lint.md

@@ -0,0 +1,27 @@
+## Lint & Format
+
+**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 running linters and formatters on the current project and fixing any issues.
+
+1. Detect the project type by checking for config files:
+   - `package.json` → Node/TS project
+   - `pyproject.toml` / `setup.py` → Python project
+   - Both → run both
+
+2. For TypeScript/JavaScript projects:
+   - Check that `eslint.config.js` uses `@mikey-pro/eslint-config` if this is a JS/TS project (per project standards). Do NOT add `eslint-disable` inline comments — the mikey-pro config has `noInlineConfig: true`.
+   - Run `npx prettier --write .` to format
+   - Run `npx eslint --fix .` to lint and auto-fix
+   - If either command fails, report the errors
+
+3. For Python projects:
+   - Run `ruff check --fix .` to lint and auto-fix
+   - Run `ruff format .` to format
+   - If ruff is not available, try `python -m black .` and `python -m flake8 .`
+
+4. Run `git diff --stat` to show what changed
+
+5. Report: what was fixed, what still has errors, and whether any files were modified

package/claude/commands/merge-all.md

@@ -0,0 +1,115 @@
+## Merge All PRs — Batch Review, Fix & Merge
+
+Autonomously review, fix, and merge all open PRs. Dispatches parallel subagents to review each PR simultaneously, then merges sequentially (oldest first) to avoid conflicts.
+
+### Input
+$ARGUMENTS - optional filter flags passed to `gh pr list` (e.g., `--author @me`, `--label ready-to-merge`). Default: all open PRs.
+
+### Instructions
+
+**Do NOT delegate this command to a subagent.** This is an orchestration command — Opus runs it directly and dispatches subagents for each PR.
+
+**Before starting, 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
+4. Read `docs/spikes/` for recent spikes
+
+#### Phase 1: Discover PRs
+
+1. **List all open PRs:**
+   ```bash
+   gh pr list --state open $ARGUMENTS --json number,title,headRefName,baseRefName,author,createdAt --jq 'sort_by(.number)'
+   ```
+
+2. **If zero PRs:** Report "No open PRs found." and stop.
+
+3. **Report what was found:**
+   ```
+   Found N open PRs:
+   - #1 — title (branch → base)
+   - #2 — title (branch → base)
+   ...
+   ```
+
+#### Phase 2: Parallel Review
+
+4. **Dispatch one Sonnet subagent per PR** using the Agent tool with `model: "sonnet"` and `subagent_type: "general-purpose"`. Launch ALL subagents in a single message (parallel).
+
+   Each subagent gets the same prompt as the `/merge` command's subagent prompt (Phases 1-2 only: load + review/fix loop), but with a modified ending:
+
+   **Instead of merging**, the subagent should:
+   - Complete the review and fix loop (max 3 iterations)
+   - Run pre-merge verification (CI checks, tests, lint)
+   - Report back with:
+     ```
+     PR #<number>: READY | NOT READY | NEEDS HUMAN REVIEW
+     - Review iterations: <count>
+     - Fixes applied: <list or "None">
+     - CI status: passing | failing | pending
+     - Blockers: <list or "None">
+     ```
+
+   **Inject the project context** (gathered above) into each subagent prompt.
+
+5. **Collect all subagent results.** Wait for all to complete.
+
+#### Phase 3: Sequential Merge
+
+6. **For each PR marked READY** (process in order of PR number, oldest first):
+
+   a. **Re-check CI status** (fixes may have triggered new CI runs):
+      ```bash
+      gh pr checks $PR_NUMBER
+      ```
+      If checks are still running, wait up to 5 minutes.
+
+   b. **Check for merge conflicts** (earlier merges may have created conflicts):
+      ```bash
+      gh pr view $PR_NUMBER --json mergeable --jq '.mergeable'
+      ```
+      If `CONFLICTING`, skip this PR and note it in the report.
+
+   c. **Merge:**
+      ```bash
+      gh pr merge $PR_NUMBER --merge --delete-branch
+      ```
+
+   d. **Verify:** `gh pr view $PR_NUMBER --json state --jq '.state'` should return "MERGED"
+
+7. **For PRs marked NOT READY or NEEDS HUMAN REVIEW:** Skip and include in report.
+
+#### Phase 4: Report
+
+8. **Generate summary report:**
+   ```
+   ## Merge All Report
+
+   ### Successfully Merged
+   | PR | Title | Iterations | Fixes | Status |
+   |----|-------|-----------|-------|--------|
+   | #1 | title | 0 | None | Merged |
+   | #3 | title | 2 | fix: ... | Merged |
+
+   ### Skipped
+   | PR | Title | Reason |
+   |----|-------|--------|
+   | #2 | title | Merge conflict after #1 merged |
+   | #4 | title | Requires human review approval |
+   | #5 | title | 3 fix iterations exhausted — issues remain |
+
+   ### Summary
+   - **Total PRs:** N
+   - **Merged:** N
+   - **Skipped:** N
+   - **Action needed:** [list any PRs that need manual attention]
+   ```
+
+### Critical Rules
+
+- **NEVER merge a PR that isn't READY.**
+- **Merge oldest first** to minimize conflict cascading.
+- **If a merge creates conflicts in later PRs, skip them** — don't try to resolve cross-PR conflicts.
+- **Max 3 fix iterations per PR** — same as `/merge`.
+- **Report everything** — the user needs to know what was merged, what was skipped, and why.
+- **NEVER use --squash or --rebase.** Always use --merge to preserve full git history.