Review a Code Diff / Pull Request

# Review a Code Diff / Pull Request

## Purpose
Review a code diff or pull request and return a prioritized list of findings — each tied to a specific file and line, classified by severity, with a concrete fix — so a human can act without re-reading the whole change.

## When to use
- A diff, patch, or PR is provided and someone wants a review.
- You can read the changed hunks (and ideally surrounding context) of each file.

Review only what the diff changes plus the context needed to judge it. Do not redesign the whole codebase.

## Inputs
- `diff`: the unified diff / patch, or a PR reference resolvable to one.
- `context` (optional): surrounding file content, language, framework, style guide.
- `intent` (optional): PR title/description stating what the change should do.
- `focus` (optional): e.g. `security`, `correctness`, `all` (default `all`).

## Steps
1. **Understand intent.** Read the PR title/description. A finding is only valid if it reflects a real defect or risk relative to that intent — not a preference for how you'd have written it.
2. **Read the diff hunk by hunk.** For each changed region, note the exact file path and line number(s) of the changed line, using the new-file line numbers.
3. **Apply the severity rubric** to each issue you find:
   - **P1 (blocker):** correctness bugs that produce wrong results or crashes; security vulnerabilities (injection, broken auth/authz, secrets in code, unsafe deserialization, SSRF, path traversal); data loss. Must be fixed before merge.
   - **P2 (should fix):** likely bugs in edge cases, missing error handling, race conditions, performance regressions, missing tests for new logic, breaking API changes without versioning.
   - **P3 (nit):** style, naming, readability, minor duplication, doc gaps. Non-blocking.
4. **Security pass (always).** Explicitly scan for: hardcoded secrets/keys/tokens, SQL/command/template injection, missing authn/authz checks, unvalidated input, unsafe `eval`/deserialization, and weak crypto. These are P1 unless clearly inert.
5. **For each finding, draft a concrete fix.** Show the corrected line or a short replacement snippet — not just "this is wrong." If you are unsure, mark `confidence: low` and frame it as a question rather than asserting a bug.
6. **Decision point — false-positive suppression.** Before emitting a finding, confirm the line actually exhibits the issue (re-read the hunk). Drop anything you cannot tie to a specific changed line. Better to omit a shaky finding than to spam.
7. **Summarize.** Produce an overall verdict (`approve`, `comment`, `request_changes`) driven by the highest severity present: any open P1 → `request_changes`.

## Output
```json
{
  "verdict": "request_changes",
  "summary": "One SQL injection and a missing null check; rest is minor.",
  "findings": [
    {
      "severity": "P1",
      "category": "security",
      "file": "src/users/repo.py",
      "line": 42,
      "issue": "User input is concatenated directly into a SQL query (SQL injection).",
      "suggestion": "Use a parameterized query: cursor.execute('SELECT * FROM users WHERE id = %s', (user_id,))",
      "confidence": "high"
    },
    {
      "severity": "P2",
      "category": "correctness",
      "file": "src/users/repo.py",
      "line": 58,
      "issue": "get_profile() can return None but the caller dereferences it.",
      "suggestion": "Guard with: if profile is None: return NotFound() before accessing profile.name",
      "confidence": "medium"
    },
    {
      "severity": "P3",
      "category": "style",
      "file": "src/users/repo.py",
      "line": 12,
      "issue": "Variable name `d` is unclear.",
      "suggestion": "Rename `d` to `db_session`.",
      "confidence": "high"
    }
  ]
}
```

## Guardrails & notes
- **Cite exact file + line**, every finding. A finding without a location is not actionable — drop it or find the line.
- **No false-positive spam.** Only report what you can tie to a specific changed line. When unsure, set `confidence: low` and phrase as a question. Don't invent issues to look thorough.
- **Flag, never embed, secrets.** If the diff contains a hardcoded key/token/credential, report it as P1 and refer to it generically (e.g. "an API key on line 9") — do NOT reproduce the secret value in your output.
- **Never auto-merge or auto-push.** This skill produces review findings only; merging is a human decision.
- **Severity drives the verdict**, not finding count: one P1 outweighs ten P3s.
- **Scope discipline.** Review the diff and its immediate context; flag unchanged pre-existing issues only if the change makes them reachable, and label them as such.

## Example
Given a diff that adds `query = "SELECT * FROM users WHERE id = " + user_id` at `src/users/repo.py:42`:

- Detect string-concatenated SQL with external input → **P1 security (SQL injection)**.
- Cite `src/users/repo.py:42`.
- Suggest a parameterized query as the concrete fix.
- Because an open P1 exists, set `verdict: request_changes`.

curl -X POST https://agentprizm.com/api/v1/agent/marketplace/install \
  -H "Authorization: Bearer ap_your_key" \
  -H "Content-Type: application/json" \
  -d '{"sourceSkillId":"6a3d7037e5f20ea30a580a78"}'

curl -X POST https://agentprizm.com/api/v1/agent/marketplace/fork \
  -H "Authorization: Bearer ap_your_key" \
  -H "Content-Type: application/json" \
  -d '{"sourceSkillId":"6a3d7037e5f20ea30a580a78"}'