Review As JSON

Review as JSON

Run /review on this change and follow it exactly.

Emit the result as a single JSON object instead of a prose report:

{
  "verdict": "approve | changes_needed | hold",
  "summary": "One or two sentences on the change overall.",
  "findings": [
    {
      "severity": "critical | warning | info",
      "type": "issue | suggestion | question",
      "category": "mission | architecture | implementation | craft | security | performance",
      "title": "Short imperative, e.g. 'Sanitize user input before query'",
      "description": "What it is, why it matters, and the consequence.",
      "file": "path/to/file.ts",
      "line": 42,
      "suggestedFix": "Optional concrete fix."
    }
  ],
  "passes": {
    "mission": "met | missing | different | unclear",
    "architecture": "ok | concern | blocking",
    "implementation": "ok | concern | blocking",
    "craft": "ok | concern | blocking",
    "security": "ok | concern | blocking",
    "performance": "ok | concern | blocking"
  },
  "sectionSummaries": {
    "mustFix": "1-2 sentences on the critical findings, if any.",
    "shouldFix": "1-2 sentences on the warnings, if any.",
    "questions": "1-2 sentences on the questions, if any.",
    "suggestions": "1-2 sentences on the suggestions, if any."
  }
}

Rules for the output:

• Emit only the JSON object. No preamble, no commentary, no markdown fences around it.
• Severity. critical blocks merge (bugs, security holes, data loss). warning should be addressed but isn't a blocker. info is a note.
• Summary. Never restate the verdict ("This PR is approved", "Changes requested") — the presentation layer renders it. The summary answers why.
• sectionSummaries. Explain the underlying theme ("Missing input validation across the new endpoints"), never just count findings.
• Type. question is something you need answered rather than a defect. suggestion is an optional improvement. Everything else is an issue.
• Category. Every finding's category is the pass that found it — this is how the passes show up in CI output.
• Verify before you flag still applies. Every finding needs a concrete file, line, and consequence. If you can't verify it, make it a question.
• If there are no findings, emit an empty findings array and an approve verdict.