Review pull requests automatically

Add a first-pass reviewer to your pull requests that comments on bugs, risky changes and missing tests, leaving style to your linters and judgment to your engineers.

Flow

1. A CI job starts on each pull request and collects the diff plus the full content of changed files (context matters; a diff alone hides how code is used).
2. It calls Syntic Code with the review instructions and the material.
3. The model returns findings as structured output: file, line, severity, explanation, suggested fix.
4. The job posts findings as review comments, skipping any below your severity threshold.

Instructions that keep it useful

• Review for correctness, security and missing tests. Do not comment on formatting.
• Only report an issue you can point to a specific line for.
• Say how confident you are; omit low-confidence findings.
• Limit to the ten most important findings.

Schema

{"type": "object", "required": ["findings"], "additionalProperties": false, "properties": {
  "findings": {"type": "array", "maxItems": 10, "items": {"type": "object", "additionalProperties": false,
    "required": ["file", "line", "severity", "explanation", "suggestion"],
    "properties": {"file": {"type": "string"}, "line": {"type": "integer"},
      "severity": {"enum": ["blocker", "major", "minor"]}, "explanation": {"type": "string"}, "suggestion": {"type": ["string", "null"]}}}}}}

Authentication

Use workload identity for the CI job instead of a stored key, owned by a service account so usage shows up as the review bot.

Measure

Track how many comments engineers resolve versus dismiss. A dismissal rate above a third means the bot is noisy; raise the severity threshold or tighten the instructions.