@arthai/agents 1.0.0

package/dist/plugins/prism/hooks/post-diff-test-compare.sh

@@ -0,0 +1,125 @@
+#!/bin/bash
+# PostToolUse hook (Bash): Auto-compare test results against /fix baseline.
+# When a /fix is in progress (baseline files exist), any test run is automatically
+# compared against the pre-fix baseline to detect regressions.
+#
+# Detects: pytest, jest, vitest, go test, cargo test, npm test
+# Compares: pass/fail counts + specific test name changes
+#
+# stdout is injected as context — flags PASS→FAIL regressions immediately.
+
+set -euo pipefail
+
+COMMAND="${CLAUDE_TOOL_INPUT_COMMAND:-}"
+if [ -z "$COMMAND" ] && [ -n "${CLAUDE_TOOL_INPUT:-}" ]; then
+    COMMAND=$(echo "$CLAUDE_TOOL_INPUT" | python3 -c "import json,sys; print(json.load(sys.stdin).get('command',''))" 2>/dev/null) || true
+fi
+
+OUTPUT="${CLAUDE_TOOL_OUTPUT:-}"
+PROJECT_DIR="${CLAUDE_PROJECT_DIR:-$(pwd)}"
+
+[ -z "$COMMAND" ] && exit 0
+[ -z "$OUTPUT" ] && exit 0
+
+# ---------------------------------------------------------------------------
+# Only run if a /fix baseline exists
+# ---------------------------------------------------------------------------
+
+BASELINE_BACKEND="$PROJECT_DIR/.claude/.fix-baseline-backend.txt"
+BASELINE_FRONTEND="$PROJECT_DIR/.claude/.fix-baseline-frontend.txt"
+
+# No baselines = no /fix in progress = nothing to compare
+[ -f "$BASELINE_BACKEND" ] || [ -f "$BASELINE_FRONTEND" ] || exit 0
+
+# ---------------------------------------------------------------------------
+# Detect test runner
+# ---------------------------------------------------------------------------
+
+IS_TEST=false
+BASELINE_FILE=""
+
+# Python (pytest)
+if echo "$COMMAND" | grep -qE '\bpytest\b|python\s+-m\s+pytest'; then
+    IS_TEST=true
+    BASELINE_FILE="$BASELINE_BACKEND"
+fi
+
+# Node (jest, vitest, npm test)
+if echo "$COMMAND" | grep -qE '\bjest\b|\bvitest\b|npm\s+test|npx\s+(jest|vitest)'; then
+    IS_TEST=true
+    BASELINE_FILE="$BASELINE_FRONTEND"
+fi
+
+# Go
+if echo "$COMMAND" | grep -qE '\bgo\s+test\b'; then
+    IS_TEST=true
+    BASELINE_FILE="$BASELINE_BACKEND"
+fi
+
+# Rust
+if echo "$COMMAND" | grep -qE '\bcargo\s+test\b'; then
+    IS_TEST=true
+    BASELINE_FILE="$BASELINE_BACKEND"
+fi
+
+$IS_TEST || exit 0
+[ -f "$BASELINE_FILE" ] || exit 0
+
+# ---------------------------------------------------------------------------
+# Extract pass/fail from current run
+# ---------------------------------------------------------------------------
+
+extract_counts() {
+    local text="$1"
+    local passed=0 failed=0
+
+    # pytest: "X passed, Y failed"
+    passed=$(echo "$text" | grep -oE '[0-9]+ passed' | grep -oE '[0-9]+' | head -1) || true
+    failed=$(echo "$text" | grep -oE '[0-9]+ failed' | grep -oE '[0-9]+' | head -1) || true
+
+    # jest/vitest: "Tests: X passed, Y failed"
+    if [ -z "$passed" ]; then
+        passed=$(echo "$text" | grep -oE 'Tests:.*[0-9]+ passed' | grep -oE '[0-9]+ passed' | grep -oE '[0-9]+') || true
+        failed=$(echo "$text" | grep -oE 'Tests:.*[0-9]+ failed' | grep -oE '[0-9]+ failed' | grep -oE '[0-9]+') || true
+    fi
+
+    # go test: "ok" lines = passed, "FAIL" lines = failed
+    if [ -z "$passed" ]; then
+        passed=$(echo "$text" | grep -c "^ok" 2>/dev/null) || true
+        failed=$(echo "$text" | grep -c "^FAIL" 2>/dev/null) || true
+    fi
+
+    echo "${passed:-0} ${failed:-0}"
+}
+
+# Extract from baseline
+read BASELINE_PASSED BASELINE_FAILED <<< "$(extract_counts "$(cat "$BASELINE_FILE")")"
+
+# Extract from current run
+read CURRENT_PASSED CURRENT_FAILED <<< "$(extract_counts "$OUTPUT")"
+
+# ---------------------------------------------------------------------------
+# Compare and report
+# ---------------------------------------------------------------------------
+
+# Calculate changes
+NEW_FAILURES=$((${CURRENT_FAILED:-0} - ${BASELINE_FAILED:-0}))
+NEW_PASSES=$((${CURRENT_PASSED:-0} - ${BASELINE_PASSED:-0}))
+
+if [ "${NEW_FAILURES:-0}" -gt 0 ]; then
+    echo "⚠️ DIFFERENTIAL TEST WARNING: ${NEW_FAILURES} new failure(s) detected vs pre-fix baseline"
+    echo "  Baseline: ${BASELINE_PASSED} passed, ${BASELINE_FAILED} failed"
+    echo "  Current:  ${CURRENT_PASSED} passed, ${CURRENT_FAILED} failed"
+    echo "  → ${NEW_FAILURES} test(s) went from PASS → FAIL — fix may have side effects"
+    echo "  Check the behavior contract: are these expected changes or regressions?"
+elif [ "${NEW_PASSES:-0}" -gt 0 ] && [ "${NEW_FAILURES:-0}" -le 0 ]; then
+    echo "✓ Differential test: ${NEW_PASSES} new pass(es), 0 new failures (fix looks clean)"
+    echo "  Baseline: ${BASELINE_PASSED} passed, ${BASELINE_FAILED} failed"
+    echo "  Current:  ${CURRENT_PASSED} passed, ${CURRENT_FAILED} failed"
+elif [ "${CURRENT_PASSED:-0}" -eq "${BASELINE_PASSED:-0}" ] && [ "${CURRENT_FAILED:-0}" -eq "${BASELINE_FAILED:-0}" ]; then
+    echo "ℹ️ Differential test: no change from baseline (${CURRENT_PASSED} passed, ${CURRENT_FAILED} failed)"
+    echo "  If this is after applying the fix, the bug-related tests should have changed."
+    echo "  Check: did the fix actually change the test outcomes?"
+fi
+
+exit 0

package/dist/plugins/prism/hooks/post-test-summary.sh

@@ -0,0 +1,115 @@
+#!/bin/bash
+# PostToolUse hook (Bash): Summarize test results after test runs.
+# Detects pytest, jest, vitest, playwright output and injects a compact summary.
+#
+# stdout is injected as context.
+
+set -euo pipefail
+
+# Extract the command that was run
+COMMAND="${CLAUDE_TOOL_INPUT_COMMAND:-}"
+if [ -z "$COMMAND" ] && [ -n "${CLAUDE_TOOL_INPUT:-}" ]; then
+    COMMAND=$(echo "$CLAUDE_TOOL_INPUT" | python3 -c "import json,sys; print(json.load(sys.stdin).get('command',''))" 2>/dev/null) || true
+fi
+
+# Get the tool output
+OUTPUT="${CLAUDE_TOOL_OUTPUT:-}"
+
+[ -z "$COMMAND" ] && exit 0
+[ -z "$OUTPUT" ] && exit 0
+
+# ---------------------------------------------------------------------------
+# Detect test runner and parse results
+# ---------------------------------------------------------------------------
+
+# pytest
+if echo "$COMMAND" | grep -qE '\bpytest\b|python\s+-m\s+pytest'; then
+    # Look for the summary line: "X passed, Y failed, Z errors in Ns"
+    summary_line=$(echo "$OUTPUT" | grep -oE '[0-9]+ passed|[0-9]+ failed|[0-9]+ error' | head -5) || true
+
+    if [ -n "$summary_line" ]; then
+        passed=$(echo "$summary_line" | grep -oE '[0-9]+ passed' | grep -oE '[0-9]+') || echo "0"
+        failed=$(echo "$summary_line" | grep -oE '[0-9]+ failed' | grep -oE '[0-9]+') || echo "0"
+        errors=$(echo "$summary_line" | grep -oE '[0-9]+ error' | grep -oE '[0-9]+') || echo "0"
+
+        echo "TEST SUMMARY (pytest): ${passed:-0} passed, ${failed:-0} failed, ${errors:-0} errors"
+
+        # Extract failure names (FAILED lines)
+        if [ "${failed:-0}" -gt 0 ] || [ "${errors:-0}" -gt 0 ]; then
+            echo "  Failures:"
+            echo "$OUTPUT" | grep -E '^FAILED |^ERROR ' | head -5 | while read -r line; do
+                echo "    ${line}"
+            done
+        fi
+    fi
+    exit 0
+fi
+
+# jest / vitest
+if echo "$COMMAND" | grep -qE '\bnpm\s+test\b|\bnpx\s+(jest|vitest)\b|\bvitest\b'; then
+    # Jest summary: "Test Suites: X passed, Y failed" / "Tests: X passed, Y failed"
+    suite_line=$(echo "$OUTPUT" | grep -oE 'Test Suites:.*' | head -1) || true
+    test_line=$(echo "$OUTPUT" | grep -oE 'Tests:.*' | head -1) || true
+
+    if [ -n "$suite_line" ] || [ -n "$test_line" ]; then
+        echo "TEST SUMMARY (jest/vitest):"
+        [ -n "$suite_line" ] && echo "  ${suite_line}"
+        [ -n "$test_line" ] && echo "  ${test_line}"
+
+        # Extract failed test names
+        echo "$OUTPUT" | grep -E '✕|✗|FAIL ' | head -5 | while read -r line; do
+            echo "  ${line}"
+        done
+    fi
+    exit 0
+fi
+
+# playwright
+if echo "$COMMAND" | grep -qE '\bplaywright\s+test\b'; then
+    # Playwright summary: "X passed" / "X failed"
+    summary=$(echo "$OUTPUT" | grep -oE '[0-9]+ passed|[0-9]+ failed|[0-9]+ skipped' | head -5) || true
+
+    if [ -n "$summary" ]; then
+        passed=$(echo "$summary" | grep -oE '[0-9]+ passed' | grep -oE '[0-9]+') || echo "0"
+        failed=$(echo "$summary" | grep -oE '[0-9]+ failed' | grep -oE '[0-9]+') || echo "0"
+
+        echo "TEST SUMMARY (playwright): ${passed:-0} passed, ${failed:-0} failed"
+
+        if [ "${failed:-0}" -gt 0 ]; then
+            echo "  Failed tests:"
+            echo "$OUTPUT" | grep -E '✘|FAILED|failed' | head -5 | while read -r line; do
+                echo "    ${line}"
+            done
+        fi
+    fi
+    exit 0
+fi
+
+# Lint checks (ruff, eslint)
+if echo "$COMMAND" | grep -qE '\bruff\s+check\b'; then
+    error_count=$(echo "$OUTPUT" | grep -cE '^\S+:\d+:\d+:' 2>/dev/null) || echo "0"
+    if [ "${error_count:-0}" -gt 0 ]; then
+        echo "LINT SUMMARY (ruff): ${error_count} issues found"
+        # Show first 3 errors
+        echo "$OUTPUT" | grep -E '^\S+:\d+:\d+:' | head -3 | while read -r line; do
+            echo "  ${line}"
+        done
+        [ "$error_count" -gt 3 ] && echo "  ... and $((error_count - 3)) more"
+    fi
+    exit 0
+fi
+
+# TypeScript type check
+if echo "$COMMAND" | grep -qE '\btsc\s+--noEmit\b'; then
+    error_count=$(echo "$OUTPUT" | grep -cE '^.+\(\d+,\d+\): error' 2>/dev/null) || echo "0"
+    if [ "${error_count:-0}" -gt 0 ]; then
+        echo "TYPE CHECK SUMMARY (tsc): ${error_count} type errors"
+        echo "$OUTPUT" | grep -E '^.+\(\d+,\d+\): error' | head -3 | while read -r line; do
+            echo "  ${line}"
+        done
+        [ "$error_count" -gt 3 ] && echo "  ... and $((error_count - 3)) more"
+    fi
+    exit 0
+fi
+
+exit 0

package/dist/plugins/prism/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/dist/plugins/prism/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/dist/plugins/prism/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."

package/dist/plugins/scalpel/.claude-plugin/plugin.json

@@ -0,0 +1,6 @@
+{
+  "name": "scalpel",
+  "description": "Surgical bug fixing — targeted fixes, CI repair, issue triage",
+  "version": "1.0.0",
+  "author": "Arth AI"
+}

package/dist/plugins/scalpel/agents/code-reviewer.md

@@ -0,0 +1,115 @@
+---
+name: code-reviewer
+description: |
+  Use this agent when a major project step has been completed and needs to be reviewed against the original plan and coding standards. Examples: <example>Context: The user is creating a code-review agent that should be called after a logical chunk of code is written. user: "I've finished implementing the user authentication system as outlined in step 3 of our plan" assistant: "Great work! Now let me use the code-reviewer agent to review the implementation against our plan and coding standards" <commentary>Since a major project step has been completed, use the code-reviewer agent to validate the work against the plan and identify any issues.</commentary></example> <example>Context: User has completed a significant feature implementation. user: "The API endpoints for the task management system are now complete - that covers step 2 from our architecture document" assistant: "Excellent! Let me have the code-reviewer agent examine this implementation to ensure it aligns with our plan and follows best practices" <commentary>A numbered step from the planning document has been completed, so the code-reviewer agent should review the work.</commentary></example>
+model: inherit
+---
+
+You are a Senior Code Reviewer with expertise in software architecture, design patterns, and best practices. Your role is to review completed project steps against original plans and ensure code quality standards are met.
+
+## Project Context Discovery
+
+### Project Context Sources
+
+Read these before reviewing ANY code:
+1. `.claude/project-profile.md` — architecture, conventions, domain model (from /calibrate)
+2. `.claude/knowledge/shared/conventions.md` — coding rules learned from corrections
+3. `.claude/knowledge/shared/patterns.md` — established architecture patterns
+4. `.claude/knowledge/skills/review-pr.md` — past review patterns for this project
+5. `.claude/qa-knowledge/bug-patterns.md` — known bug patterns to watch for
+
+Use these to calibrate your review:
+- Match code quality checks to the project's ACTUAL conventions (not generic best practices)
+- Flag violations of established patterns from the knowledge base
+- Check if changed files have had past bugs (from incidents/)
+- Apply project-specific review criteria from the profile
+
+Before reviewing, read `CLAUDE.md` in the project root for:
+- Tech stack, frameworks, and conventions
+- Security requirements and auth patterns
+- Testing standards and coverage thresholds
+
+## CRITICAL: Always Produce Structured Output
+
+Your review MUST ALWAYS include a structured findings section with explicit severity labels.
+Even if no issues are found, output the structure with "No issues found" under each category.
+
+**Required output format:**
+```
+## Security Review
+- **[CRITICAL]** / **[HIGH]** / **[MEDIUM]** / **[LOW]** — description of finding
+  - File: path/to/file.py:line
+  - Risk: what could go wrong
+  - Fix: specific remediation
+
+## Code Quality Review
+- **[severity]** — description
+  ...
+
+## Summary
+- Security issues: N (X critical, Y high, Z medium)
+- Code quality issues: N
+- Recommendation: APPROVE / REQUEST CHANGES / BLOCK
+```
+
+When reviewing for security specifically, ALWAYS check for:
+- Missing authentication on endpoints (especially DELETE, PUT, PATCH)
+- SQL injection via string interpolation/f-strings in queries
+- Missing input validation/sanitization
+- Hardcoded secrets or credentials
+- Missing authorization checks (ownership, role-based access)
+
+When reviewing completed work, you will:
+
+1. **Plan Alignment Analysis**:
+   - Compare the implementation against the original planning document or step description
+   - Identify any deviations from the planned approach, architecture, or requirements
+   - Assess whether deviations are justified improvements or problematic departures
+   - Verify that all planned functionality has been implemented
+
+2. **Code Quality Assessment**:
+   - Review code for adherence to established patterns and conventions
+   - Check for proper error handling, type safety, and defensive programming
+   - Evaluate code organization, naming conventions, and maintainability
+   - Assess test coverage and quality of test implementations
+   - Look for potential security vulnerabilities or performance issues
+
+3. **Architecture and Design Review**:
+   - Ensure the implementation follows SOLID principles and established architectural patterns
+   - Check for proper separation of concerns and loose coupling
+   - Verify that the code integrates well with existing systems
+   - Assess scalability and extensibility considerations
+
+4. **Documentation and Standards**:
+   - Verify that code includes appropriate comments and documentation
+   - Check that file headers, function documentation, and inline comments are present and accurate
+   - Ensure adherence to project-specific coding standards and conventions
+
+5. **Issue Identification and Recommendations**:
+   - Clearly categorize issues as: Critical (must fix), Important (should fix), or Suggestions (nice to have)
+   - For each issue, provide specific examples and actionable recommendations
+   - When you identify plan deviations, explain whether they're problematic or beneficial
+   - Suggest specific improvements with code examples when helpful
+
+6. **Communication Protocol**:
+   - If you find significant deviations from the plan, ask the coding agent to review and confirm the changes
+   - If you identify issues with the original plan itself, recommend plan updates
+   - For implementation problems, provide clear guidance on fixes needed
+   - Always acknowledge what was done well before highlighting issues
+
+Your output should be structured, actionable, and focused on helping maintain high code quality while ensuring project goals are met. Be thorough but concise, and always provide constructive feedback that helps improve both the current implementation and future development practices.
+
+## Knowledge Base Integration
+
+### On every review:
+1. Read `knowledge/shared/conventions.md` — review against actual project conventions
+2. Read `knowledge/skills/review-pr.md` — check for recurring review patterns
+3. Read `qa-knowledge/bug-patterns.md` — flag code in areas with known bugs
+
+### After review:
+- Append recurring findings to `knowledge/skills/review-pr.md`
+- If you discover a convention not in the knowledge base, append to `knowledge/shared/conventions.md`
+
+### /calibrate Integration
+If project-profile.md exists, use its conventions for review criteria.
+If it doesn't, recommend running /calibrate for better code review accuracy.

package/dist/plugins/scalpel/hooks/hooks.json

@@ -0,0 +1,26 @@
+{
+  "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "Edit",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "${CLAUDE_PLUGIN_ROOT}/hooks/pre-edit-guard.sh",
+            "timeout": 5
+          }
+        ]
+      },
+      {
+        "matcher": "Write",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "${CLAUDE_PLUGIN_ROOT}/hooks/pre-edit-guard.sh",
+            "timeout": 5
+          }
+        ]
+      }
+    ]
+  }
+}