@arthai/agents 1.0.0

package/skills/pr/SKILL.md

@@ -0,0 +1,275 @@
+---
+name: pr
+description: Run QA, create a GitHub PR, and manage post-merge workflow. Never push directly to main.
+user-invocable: true
+---
+
+# /pr — Ship Code Safely
+
+## CRITICAL SAFETY RULE — Destructive Operations
+**NEVER** delete projects, services, repos, databases, or large infrastructure sections on Railway, GitHub (ArthTech-AI org), or any platform without asking the user **3 separate times** for explicit confirmation. This includes `railway delete`, `gh repo delete`, `rm -rf`, `DROP DATABASE`, service removal, etc. When in doubt, ASK.
+
+## Project Context Discovery
+
+Before creating any PR, understand the project's conventions. This ensures PRs match the team's
+expectations regardless of platform.
+
+### Step 1: Read existing context
+
+Read in this order (skip gracefully if missing):
+1. `CLAUDE.md` — Critical Rules, test commands, infrastructure
+2. `.claude/project-profile.md` — Coding conventions, commit style, PR process
+3. `.claude/knowledge/shared/conventions.md` — Learned team conventions
+4. `.claude/knowledge/skills/pr.md` — Past PR patterns for this project
+
+### Step 2: Detect source control platform
+
+| Signal | Platform | PR Command |
+|--------|----------|-----------|
+| `.git/config` contains `github.com` | GitHub | `gh pr create` |
+| `.git/config` contains `gitlab.com` or GitLab self-hosted | GitLab | `glab mr create` |
+| `.git/config` contains `bitbucket.org` | Bitbucket | Bitbucket API |
+| `.git/config` contains `dev.azure.com` | Azure DevOps | `az repos pr create` |
+
+Default: GitHub (most common). If platform can't be detected, ask user.
+
+### Step 3: Detect commit and PR conventions
+
+**From git history (most reliable — the team's actual practice):**
+```bash
+# Detect commit style from last 20 commits
+git log --oneline -20 --format="%s"
+# Look for patterns:
+#   "feat: ..." / "fix: ..." → Conventional Commits
+#   "Add feature X" / "Fix bug Y" → Freeform imperative
+#   "[JIRA-123] Fix bug" → Ticket-prefixed
+#   "#123 Fix bug" → Issue-prefixed
+```
+
+**From config files:**
+- `commitlint.config.js` → Conventional Commits enforced
+- `.czrc` / `.cz.json` → Commitizen configured (conventional)
+- `.github/PULL_REQUEST_TEMPLATE.md` → Custom PR template exists (use it!)
+- `.github/CODEOWNERS` → Auto-reviewer assignment rules
+
+**From project-profile.md (if /calibrate has run):**
+- Commit style: conventional | freeform | ticket-prefixed
+- PR merge strategy: squash | merge commit | rebase
+- Branch naming: feature/* | feat/* | JIRA-*
+
+### Step 4: Detect PR requirements
+
+```bash
+# Check if branch protection requires reviews
+gh api repos/{owner}/{repo}/branches/main/protection --jq '.required_pull_request_reviews.required_approving_review_count' 2>/dev/null
+
+# Check if status checks are required
+gh api repos/{owner}/{repo}/branches/main/protection --jq '.required_status_checks.contexts[]' 2>/dev/null
+
+# Check if CODEOWNERS exists
+test -f .github/CODEOWNERS && echo "CODEOWNERS found — auto-reviewers will be assigned"
+```
+
+### Step 5: Build PR template
+
+Based on discovery, construct the right PR format:
+
+**If `.github/PULL_REQUEST_TEMPLATE.md` exists:**
+- Use it as the base template
+- Fill in the sections from QA results and change analysis
+
+**If project uses conventional commits:**
+- PR title: `{type}({scope}): {description}` (match commit style)
+- PR body: include breaking changes section if type is `feat!` or `fix!`
+
+**If project uses ticket-prefixed commits:**
+- PR title: `[TICKET-123] Description`
+- PR body: include ticket link
+
+**Default template (no conventions detected):**
+- Summary (1-3 bullets)
+- QA Results
+- Test plan
+- Closes #N
+
+### Step 6: Recommend improvements
+
+If missing, suggest:
+```
+PR process recommendations for {project}:
+  ⚠ No PULL_REQUEST_TEMPLATE.md — consider adding one for consistent PRs
+  ⚠ No CODEOWNERS file — PRs won't auto-assign reviewers
+  ⚠ No branch protection on main — anyone can push directly
+  ⚠ No required status checks — PRs can merge without CI passing
+  ⚠ No commit convention detected — consider conventional commits for changelogs
+```
+
+This skill orchestrates the full pre-merge workflow: QA checks, PR creation, and post-merge cleanup.
+
+## Argument Parsing
+
+| Input | Action |
+|-------|--------|
+| `/pr` | Full workflow — QA + commit + push + PR |
+| `/pr --skip-qa` | Skip QA step — used when called from `/fix` or `/implement` which already ran QA. Only runs a quick sanity check (lint + type check). |
+
+## Pre-Merge Workflow
+
+### Step 0: Run /precheck (toolkit projects only)
+
+If this is the claude-agents toolkit itself (check if `tests/run.sh` exists):
+
+1. Invoke `/precheck` to run local mechanical tests
+2. **If /precheck FAILS** — stop, fix failures, do NOT proceed
+3. **If /precheck PASSES** — continue to Step 1
+
+This catches CI failures in 30 seconds instead of a 4-minute remote round-trip.
+Skip this step for non-toolkit projects (they don't have the test harness).
+
+### Step 1: QA Gate
+
+**If `--skip-qa` flag is set** (called from `/fix` or `/implement` which already ran QA):
+
+Run a **quick sanity check only** — no full QA run:
+
+```bash
+# Read CLAUDE.md Test Commands table for lint and type check commands
+# Examples:
+#   Python: ruff check . && mypy .
+#   Node:   npm run lint && npx tsc --noEmit
+#   Go:     golangci-lint run && go vet ./...
+#   Rust:   cargo clippy && cargo check
+```
+
+If sanity check fails → show failures, ask user to fix. Do NOT run full QA.
+If sanity check passes → continue to Step 2.
+
+**If no `--skip-qa` flag** (called standalone):
+
+Run the full QA framework in commit mode:
+
+1. Invoke the `/qa` skill (commit mode) using the Skill tool
+2. Wait for QA results
+3. **If /qa FAILS** — stop immediately, show the failures, do NOT create PR
+4. **If /qa PASSES** — continue to Step 2
+
+**Why the split**: `/fix` and `/implement` both have their own QA step where the user
+chooses the QA level. Running `/qa commit` again in `/pr` would be redundant. The quick
+sanity check catches last-second issues (uncommitted lint errors, type mismatches from
+a bad merge) without re-running the full test suite.
+
+### Step 2: Stage and commit
+
+1. Check `git status` for unstaged changes
+2. Stage relevant files (never stage `.env`, credentials, or large binaries)
+3. Create a commit with a descriptive message if there are uncommitted changes
+
+### Step 3: Find or create GitHub issue
+
+Before creating the PR, ensure a tracking issue exists:
+
+1. **Check for existing issue** — search in this order:
+   a. If a PR already exists for this branch (`gh pr list --head <branch> --json body --limit 1`),
+      extract the issue number from `Closes #N` in the PR body
+   b. Search open issues for the branch name: `gh issue list --search "Branch: <branch-name>" --state open --json number,title --limit 1`
+   c. Search open issues by title keywords (derive from branch name, e.g., `fix/safari-audio` → "safari audio"):
+      `gh issue list --search "<keywords> in:title" --state open --json number,title --limit 3`
+      - If exactly 1 match, reuse it
+      - If multiple matches, show them to the user and ask which to link (or create new)
+
+2. **If no existing issue found** — create one with `gh issue create`:
+   - Title: concise description of what the change does
+   - Body: problem statement, solution summary, and a branch marker line:
+     ```
+     Branch: <branch-name>
+     ```
+     This marker enables reliable lookup on future `/pr` runs.
+
+3. Note the issue number for the PR body
+
+### Step 4: Push and create PR
+
+1. Push current branch to origin: `git push -u origin <branch>`
+2. Create a GitHub PR with:
+   - A concise title (under 70 chars) summarizing the change
+   - A body with:
+     - `## Summary` — 1-3 bullet points of what changed and why
+     - `## QA Results` — paste the /qa commit summary (pass/fail counts)
+     - `## Test plan` — checklist of what to verify
+     - `Closes #<issue-number>` — auto-closes the issue on merge
+3. Return the PR URL to the user
+
+### Step 5: Never push directly to main
+
+If on main branch, refuse and ask user to create a feature branch first.
+
+## Post-Merge Workflow
+
+After the PR is merged (user confirms or asks to clean up):
+
+1. Verify the linked issue was auto-closed (the `Closes #N` in the PR body handles this)
+2. If the issue wasn't auto-closed, close it manually: `gh issue close <number> --reason completed`
+3. Delete the remote branch: `git push origin --delete <branch>`
+4. Delete the local branch: `git branch -d <branch>`
+5. Checkout main: `git checkout main`
+6. Pull latest: `git pull origin main`
+7. **Run `/onboard`** — invoke the onboard skill to present project status (open PRs, GH issues, memory context) and recommend what to work on next
+
+## What Happens After Merge (automated by CI/CD)
+
+The user doesn't need to do anything — GitHub Actions handles:
+
+```
+Merge to main
+  → CI checks run again
+  → Deploy to staging → smoke test staging
+  → If staging healthy → deploy to production
+  → Health check production → Discord notification
+```
+
+If Discord reports issues, tell the user to run `/sre` to investigate.
+
+## Continuation (Workflow Chaining)
+
+After the PR is created:
+
+**If autopilot is active** (check `.claude/.workflow-state.json` mode == "autopilot"):
+- Update workflow state: `phase: "awaiting_merge"`, `pr_number: N`
+- Present PR summary with risk assessment
+- **STOP HERE** — never merge without human approval
+- When user says "merged", "continue", or "next": the post-git-state hook
+  will reset phase to "assess" and the autopilot loop continues
+
+**If guided mode** (no autopilot or mode != "autopilot"):
+- Present: "PR #N created. After merge, run `/onboard` to see what's next."
+- Offer the post-merge cleanup steps (delete branch, checkout main, pull)
+
+## Knowledge Base Integration
+
+### On every /pr invocation:
+1. **Read** `.claude/knowledge/shared/conventions.md` — use correct commit style
+2. **Read** `.claude/knowledge/skills/pr.md` — past PR patterns
+3. **Read** `.github/PULL_REQUEST_TEMPLATE.md` — use project's own template
+
+### After PR created:
+1. **Append** to `.claude/knowledge/skills/pr.md`:
+   ```
+   ### {date} — PR #{number}
+   **Branch**: {branch}
+   **Type**: {bug fix | feature | refactor}
+   **Files**: {count}
+   **Reviewers**: {auto-assigned from CODEOWNERS or manual}
+   **Template used**: {custom | default | conventional}
+   ```
+
+### /calibrate Integration
+
+When `/calibrate` runs, it reads the project's git history and PR configuration.
+The /pr skill contributes:
+1. **Commit convention detection** → /calibrate writes to project profile
+2. **PR template existence** → /calibrate notes in recommendations
+3. **Branch protection rules** → /calibrate notes in recommendations
+4. **CODEOWNERS rules** → /calibrate notes reviewer patterns
+
+If `/calibrate` hasn't run, /pr does its own discovery and uses what it finds.
+If `/calibrate` has run, /pr reads conventions from `project-profile.md` directly.

package/skills/precheck/SKILL.md

@@ -0,0 +1,159 @@
+---
+name: precheck
+description: "Run local tests before pushing. Catches CI failures locally in 30s instead of 4min round-trip. Usage: /precheck"
+user-invocable: true
+arguments: ""
+---
+
+# /precheck — Local CI Before Push
+
+Run the mechanical test suite locally before creating a PR. Catches failures
+in 30 seconds instead of a 4-minute CI round-trip.
+
+**Run this EVERY TIME before pushing.**
+
+## Execution
+
+### Step 1: Detect what changed
+
+```bash
+# What files changed on this branch vs main?
+CHANGED=$(git diff main...HEAD --name-only 2>/dev/null || git diff HEAD~1 --name-only)
+```
+
+### Step 2: Pick the right test suites
+
+Based on what changed, run only the relevant suites:
+
+| Files Changed | Suite | Why |
+|--------------|-------|-----|
+| `hooks/triage-router.sh` | `--suite 09` | Triage output format tests |
+| `hooks/*.sh` (any hook) | `--suite 09` | Hook execution tests |
+| `skills/*/SKILL.md` | `--suite 20` | Skill runtime safety (frontmatter, brackets) |
+| `agents/*.md` | `--suite 19,20` | Brownfield classification + skill safety |
+| `install.sh` | `--suite 01,02,03,04,19` | Install flow tests |
+| `portable.manifest` | `--suite 01,02` | Manifest consistency |
+| `tests/fixtures/**` | `--suite 19` | Brownfield fixture tests |
+| Multiple categories | `--mechanical` | Run all mechanical tests |
+
+### Step 3: Run the tests
+
+```bash
+# Must be on a feature branch (test runner refuses main)
+BRANCH=$(git branch --show-current)
+if [ "$BRANCH" = "main" ]; then
+    echo "Switch to a feature branch first: git checkout -b fix/my-change"
+    exit 1
+fi
+
+# Run the selected suites
+bash tests/run.sh --suite {selected_suites} --scenario a
+```
+
+### Step 4: Report and write marker
+
+If all pass:
+```bash
+# Write precheck marker (triage router checks this before allowing /pr)
+mkdir -p "$CLAUDE_PROJECT_DIR/.claude"
+echo "$(date +%s) $(git rev-parse --short HEAD 2>/dev/null || echo 'unknown')" > "$CLAUDE_PROJECT_DIR/.claude/.precheck-passed"
+```
+```
+✓ Precheck passed ({N} tests, {time}s)
+Ready to push.
+```
+
+If any fail:
+```bash
+# Remove stale marker on failure
+rm -f "$CLAUDE_PROJECT_DIR/.claude/.precheck-passed" 2>/dev/null || true
+```
+```
+✗ Precheck FAILED
+
+Failed tests:
+  {test name} — {failure reason}
+
+Fix these before pushing. Do NOT push with failing tests.
+```
+
+### Step 5: If all pass, ship it
+
+After tests pass, run the full ship sequence. Do NOT ask — just do it.
+
+**5.1: Stage and commit** (if uncommitted changes exist)
+```bash
+git add {relevant files — never .env or credentials}
+git commit -m "{descriptive message}
+
+Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>"
+```
+
+**5.2: Push**
+```bash
+git push -u origin {branch}
+```
+
+**5.3: Create PR**
+```bash
+gh pr create --title "{title}" --body "{body}"
+```
+
+**5.4: Merge**
+```bash
+# IMPORTANT: Never use --auto. It's not enabled on this repo.
+gh pr merge --squash
+```
+
+**5.5: Cleanup**
+```bash
+git checkout main
+git pull
+git branch -d {branch}
+```
+
+**5.6: Report**
+```
+✓ Shipped: PR #{number} merged to main
+  Tests: {N} passed, 0 failed
+  Files: {changed files summary}
+```
+
+### Full sequence (copy-paste safe)
+
+The entire ship flow as a single sequence — test, commit, push, PR, merge, cleanup:
+
+```bash
+# 1. Test
+bash tests/run.sh --suite {suites} --scenario a
+
+# 2. Commit (if needed)
+git add {files}
+git commit -m "{message}"
+
+# 3. Push + PR
+git push -u origin {branch}
+gh pr create --title "{title}" --body "{body}"
+
+# 4. Merge (NEVER use --auto)
+gh pr merge --squash
+
+# 5. Cleanup
+git checkout main && git pull && git branch -d {branch}
+```
+
+## Common Failures
+
+| Failure | Cause | Fix |
+|---------|-------|-----|
+| "classify_file returns IDENTICAL" | Agent fixture is stale — you changed an agent file | Update the fixture: `cp agents/{name}.md tests/fixtures/claude-setups/poweruser/.claude/agents/` |
+| "regex-unsafe [brackets] in arguments" | Skill frontmatter has `[brackets]` | Replace `[x]` with `<x>` in SKILL.md arguments/description |
+| "compact SPEED reminder" | Triage router compact output changed | Update test assertion in `09-triage-router-output.sh` |
+| "STALE/MODIFIED classification wrong" | Agent grew too much, ratio shifted | Check fixture agent size vs toolkit — restore original fixture if needed |
+
+## Rules
+
+- **Always run before pushing.** No exceptions.
+- **Fix failures before pushing.** Don't push hoping CI will pass.
+- **If you changed agent files**, also run `--suite 19` (brownfield fixtures).
+- **If you changed the triage router**, also run `--suite 09`.

package/skills/qa/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: qa
+description: "Run QA checks. Usage: /qa (commit), /qa full (comprehensive), /qa staging (deployed), /qa prod (read-only)."
+user-invocable: true
+arguments: "<mode>"
+---
+
+# Universal QA Framework
+
+## Mode Detection
+
+Parse the mode from the argument:
+- No argument / empty / "commit" → **commit** mode
+- "full" → **full** mode
+- "staging" → **staging** deployment verification
+- "prod" / "production" → **prod** deployment verification
+
+## Mode: {{ mode }}
+
+You are the Chief QA Agent. Execute the QA framework in **{{ mode }}** mode.
+
+### Quick Reference
+- **commit mode**: Analyze `git diff HEAD~1`, run targeted checks on changed files only, spawn 2-4 agents, generate 5-8 test scenarios, produce targeted report (~1-3 min)
+- **full mode**: Analyze `git diff main...HEAD`, run ALL checks across full codebase, spawn ALL worker agents, generate 10-15 test scenarios, comprehensive report (~10-20 min)
+- **staging mode**: Resolve staging URLs from CLAUDE.md Infrastructure table, run health + smoke + E2E against deployed staging
+- **prod mode**: Resolve production URLs from CLAUDE.md, READ-ONLY health + smoke (NO mutations)
+
+### Execution Steps
+
+1. **Read configuration**: Load `CLAUDE.md` for test commands, services, infrastructure. Also load `qa-manifest.yml` if it exists.
+
+2. **Analyze changes**:
+   - commit mode: `git diff HEAD~1 --name-only`
+   - full mode: `git diff main...HEAD --name-only` + `git log --oneline -10`
+   - staging/prod: `git log --oneline -1` (just for commit hash in report)
+
+2b. **Find related test files with explore-light** (cost: 1x Haiku):
+
+   Before planning which agents to spawn, find what tests already exist for the changed files:
+
+   ```
+   subagent_type: "explore-light"
+   prompt: "For each of these changed files, find:
+   1. Existing test files that test this code (by import, naming convention, or directory)
+   2. Whether the test file has been updated in this diff (or is stale)
+   3. Related files that SHOULD be tested but might not have tests
+
+   Changed files: {from step 2}
+   Return: mapping of source file → test file (or 'NO TEST' if missing)"
+   ```
+
+   Use the results to:
+   - Skip spawning test agents for files that have no tests (flag as coverage gap instead)
+   - Focus test agents on files that DO have tests (verify they still pass)
+   - Identify new code without tests (recommend adding them)
+
+3. **Plan test strategy** using the directory heuristic:
+   | Changed files in... | Spawn agent... |
+   |---------------------|----------------|
+   | Backend directory | backend-qa (Haiku): lint, type check, tests |
+   | Frontend directory | frontend-qa (Haiku): lint, type check, tests, build |
+   | Frontend pages/routes or E2E tests | e2e-qa (Sonnet): Playwright/Cypress |
+   | Schema/type files (both sides) | contract-qa (Haiku): schema diff |
+   | Migration files | contract-qa: migration validation |
+   | Domain-specific files | domain-qa (Sonnet): business logic checks |
+   | 5+ files changed (commit) or full mode | code-review (Sonnet): architectural review |
+
+4. **Generate test scenarios**: Think like real users. What user-facing behavior changed? What edge cases matter? What could break elsewhere?
+
+5. **Create team and spawn agents**: Use TeamCreate + TaskCreate + Task tool. Spawn ALL agents in ONE message for maximum parallelism.
+
+6. **Collect results**: Monitor TaskList, collect SendMessage results from all agents.
+
+7. **Run coverage audit**: Review if existing tests still match the codebase. Flag new code without tests, stale tests, dead tests.
+
+8. **Produce report**: Structured QA report with change analysis, check results, failures, warnings, coverage, E2E results, domain quality, code review, scenario results, and actionable next steps.
+
+9. **Cleanup**: Shutdown all agents, TeamDelete, stop QA-started servers.
+
+### Three-Layer Test Strategy
+Every QA run uses three complementary layers:
+1. **Baseline Tests** — existing test suites (regression anchor, same every run)
+2. **Generated Scenarios** — fresh every run, thinks like real users based on diff
+3. **Coverage Audit** — reviews if existing tests still match the codebase
+
+### Important Notes
+- Read CLAUDE.md for ALL project-specific paths, commands, ports, and conventions
+- Generated scenarios are NOT persisted as test files — they're one-off explorations
+- If a generated scenario catches a bug, recommend adding a permanent baseline test
+- Domain validation Tier 3 is ADVISORY ONLY — never gates deployment
+- Use 600000ms timeout for E2E Bash calls
+
+## Continuation (Workflow Chaining)
+
+After QA completes:
+
+**If autopilot is active** (check `.claude/.workflow-state.json` mode == "autopilot"):
+- If QA **passed**: proceed to `/review-pr` then `/pr`
+  - Detect change type: if `.claude/.fix-scope-lock.json` exists → bug fix, else → feature
+  - Run `/review-pr --type {bug|feature}` for automated review
+  - If review passes → update workflow state: `phase: "pr"`, create PR
+  - If review has blocking issues → attempt fix, re-run QA + review
+- If QA **failed**: attempt fix (max 2 rounds), then re-run QA
+  - If still failing after 2 attempts: STOP, report failures, wait for human
+  - Update workflow state: `phase: "blocked"`, increment `attempts.qa_fixes`
+
+**If guided mode** (no autopilot or mode != "autopilot"):
+- If QA **passed**:
+  - Detect change type:
+    - `.claude/.fix-scope-lock.json` exists → this is a **bug fix**
+    - `.claude/plans/*.md` was referenced → this is a **feature**
+    - Neither → ask user or default to feature
+  - Present:
+    ```
+    QA passed. Next step: code review before creating PR.
+
+    Detected: {bug fix | feature}
+    Recommended: /review-pr {--type bug | --type feature}
+
+    This will check: {scope compliance + regression test (bug) | plan completeness + test coverage (feature)}
+    Then: /pr to create the pull request.
+
+    Run /review-pr now? Or skip to /pr?
+    ```
+  - If user says "skip" → proceed to `/pr` directly
+  - If user approves → run `/review-pr`, then suggest `/pr`
+- If QA **failed**: "QA found N failures. Here's what went wrong: [details]. Should I fix and re-run?"

package/skills/qa-incident/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: qa-incident
+description: "Manually create a QA incident from a known issue. Usage: /qa-incident <description>"
+user-invocable: true
+arguments: "<description>"
+---
+
+# Create QA Incident
+
+Manually log a production incident or known issue to the QA knowledge base, so the next `/qa` run generates a regression test for it.
+
+## Process
+
+1. **Parse the description** from the argument.
+
+2. **Ask clarifying questions** (use AskUserQuestion):
+   - Severity: high / medium / low
+   - Affected files (if known)
+   - Root cause (if known)
+
+3. **Create incident file** at `.claude/qa-knowledge/incidents/{date}-{slug}.md`:
+
+```markdown
+---
+date: {today YYYY-MM-DD}
+severity: {from user}
+status: uncovered
+affected_files:
+  - {from user, or "unknown"}
+---
+# {Title from description}
+
+## Root Cause
+{From user, or "To be investigated"}
+
+## How QA Missed It
+{Infer from context, or "Unknown -- needs investigation"}
+
+## Regression Test Recommendation
+{Suggest based on description and affected files}
+```
+
+4. **Confirm to user**: "Incident logged. Next `/qa` run will generate a regression test targeting this issue."
+
+## If No Description Provided
+
+Ask: "Describe the issue you want to log (e.g., 'admin page crashes when user has no sessions')"
+
+## If Knowledge Base Doesn't Exist
+
+Create the directory structure first:
+```bash
+mkdir -p .claude/qa-knowledge/incidents
+```

package/skills/qa-learn/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: qa-learn
+description: "Review QA knowledge base stats, prune stale entries, show learning metrics. Usage: /qa-learn [prune]"
+user-invocable: true
+arguments: "<command>"
+---
+
+# QA Learning Review
+
+Review the self-improving QA system's accumulated knowledge.
+
+## Default: Show Stats
+
+Read and summarize the QA knowledge base:
+
+1. **Incidents**: Count files in `.claude/qa-knowledge/incidents/`. Show covered vs uncovered.
+2. **Promoted tests**: Count files in `.claude/qa-knowledge/promoted-tests/`. List test file paths.
+3. **Bug patterns**: Count patterns in `.claude/qa-knowledge/bug-patterns.md`.
+4. **Coverage gaps**: Count gaps in `.claude/qa-knowledge/coverage-gaps.md`.
+5. **Challenger log**: Count entries in `.claude/qa-knowledge/challenger-log.md`. Show hit rate (attacks that found issues / total attacks).
+
+Present as a structured table:
+
+| Metric | Count | Details |
+|--------|-------|---------|
+| Incidents (uncovered) | N | {list titles} |
+| Incidents (covered) | N | {list titles} |
+| Promoted tests | N | {list file paths} |
+| Bug patterns | N | |
+| Coverage gaps | N | |
+| Challenger attacks (total) | N | |
+| Challenger hit rate | X% | {found issues / total} |
+
+## `/qa-learn prune`
+
+Remove stale entries:
+1. Incidents with `status: covered` older than 30 days -> archive or delete
+2. Promoted tests whose source test file no longer exists -> remove provenance
+3. Coverage gaps that now have test coverage -> remove
+4. Challenger log entries older than 90 days -> truncate
+
+Report what was pruned.
+
+## If Knowledge Base Doesn't Exist
+
+If `.claude/qa-knowledge/` doesn't exist, report:
+"QA knowledge base not initialized. Run `/qa commit` or `/qa full` to start accumulating knowledge."