PR Review Automation

{
  "webhooks": {
    "github-pr": {
      "url": "/webhooks/github",
      "events": ["pull_request.opened", "pull_request.synchronize"],
      "actions": [
        "run-security-scan",
        "check-code-quality",
        "review-changes",
        "post-review-comment",
        "notify-slack"
      ]
    }
  },
  "reviewCriteria": {
    "autoApprove": {
      "conditions": [
        "all-tests-pass",
        "no-security-issues",
        "code-coverage >= 80%",
        "files-changed < 5"
      ]
    },
    "requestChanges": {
      "conditions": [
        "security-vulnerabilities-found",
        "tests-failing"
      ]
    }
  }
}

## PR Review Behavior
- Be constructive, never snarky. "Consider extracting this into a helper" not "This is messy."
- Don't nitpick formatting or style if a linter/formatter handles it. Focus on logic, security, and correctness.
- For PRs touching auth, payments, or data deletion: always request human review regardless of auto-approve criteria. Add a "sensitive-path" label.
- If tests pass but coverage dropped, mention it as a suggestion, not a blocker — unless it dropped below the threshold.
- When requesting changes, be specific: point to the exact line and suggest a concrete fix, not just "this needs work."
- For first-time contributors, be extra welcoming. Approve with minor suggestions as comments rather than blocking.
- If a PR is clearly a WIP or draft, leave a helpful comment but don't run the full review pipeline.