Categories

PR Review: Targeted Review Comments & Fix Plan (Template)

Convert a PR diff into grouped, actionable review comments, minimal patches, and verification artifacts for fast triage and safe merges.

What You'll Get

• Grouped review comments by category (Correctness, Security, Concurrency, Performance, API compatibility, Test gaps, Style) where each comment includes line context, suggested patch snippet, rationale, severity (blocker/major/minor), and tests to add.

• Ranked root-cause hypotheses, expanded diagnosis tied to diff lines, and a prioritized step-by-step fix plan with risk estimates and rollback criteria.

• Minimal unified-diff patch suggestions for high/major issues, exact test names and assertions to add, a local/CI verification checklist, and clear acceptance criteria and post-merge risk checks.

• A compact remediation priority list (1-5) and a short list of top regressions to monitor after merging.

How to Use

• 1Provide the full PR diff/patch as the required input (unified diff or Gerrit/GitHub patch). If the diff is >5k LOC, split into focused chunks and run the prompt per chunk.

• 2Specify the tech stack (primary language/framework) exactly, e.g., "Node 18 + TypeScript + Express" or "Go 1.20 + Gin" and state coding/security/perf constraints (lint rules, OWASP level, no behavior change, etc.).

• 3Set desired output format to Markdown (the template is optimized for Markdown). If inputs are missing (diff, language, or constraints), the prompt will list the minimal missing artifacts and stop.

• 4Optional: attach failing tests, CI logs, or a short incident summary to improve diagnostic accuracy. Expect the model to generate review comments, minimal diffs, and a verification checklist you can copy into a PR review or ticket.

Maximize precision: include failing logs and exact stack info

When possible, include failing test output, a small repro log snippet, and the exact runtime (e.g., Node version, Go version, DB vendor). That lets the prompt produce precise line-linked diagnosis, reproduce checklists, and targeted tests instead of speculative guidance.

Works Best With

Best used when you can provide a PR diff + primary tech stack + constraints

• Provide the exact PR diff or unified patch (required).

• Specify the primary language and framework (e.g., "Node 18 + TypeScript + Express", "Go 1.20").

• List constraints and standards (e.g., OWASP level, no public API changes, small diff preferred).

• Include failing logs/tests or runtime config when available to remove unknowns.

• Choose output_format: checklist / stepwise plan / rubric to control structure of deliverable.

Prompt Template

## Goal
- Produce an engineering-grade PR review for {{repo_name_or_url}} that generates targeted review comments grouped by category (correctness, security, concurrency, performance, API compatibility, test gaps), and also produces hypotheses → diagnosis → minimal fix plan → patch guidance → verification tests.

## Inputs
- Required: the PR diff or patch to review: {{pr_diff}}
- Required: primary language/tech stack for context (e.g., "Go + Gin", "Node 18 + TypeScript + Express"): {{language_stack}}
- Required: constraints and coding/security/perf standards to follow (e.g., "no behavior change, small diff, follow repo lint rules, OWASP level: high"): {{constraints_and_standards}}
- Required: desired output format (choose one: checklist / stepwise plan / rubric): {{output_format}}
- Optional but helpful: failing test output, production incidents, related issues, or pipeline logs
- If any required input is missing, respond with a concise list of the minimal missing artifacts and stop.

## Prompt
Copy-paste and run the following prompt (replace placeholders above in this template before sending to the model):

You are an expert senior engineer and security reviewer. Review the supplied PR diff for {{repo_name_or_url}} using this diff: {{pr_diff}}. Use the tech context: {{language_stack}} and enforce constraints/standards: {{constraints_and_standards}}. Produce the results in {{output_format}} form. Your deliverables must include hypotheses → diagnosis → fix plan → patch guidance → tests, and a grouped set of review comments.

Deliverables (strict format requirements):
1) Top-level summary (1-3 sentences): overall risk level (low/medium/high), recommended disposition (approve/changes requested/block).
2) Assumptions and Unknowns: list any missing context that would materially change your review.
3) For each category produce a grouped list of review comments. Categories (in this order): Correctness, Security, Concurrency, Performance, API compatibility, Test gaps, Style/Other. For each comment include:
   - id: short unique id (e.g., CORR-1)
   - category: one of the categories above
   - severity: blocker / major / minor
   - file and line context: provide the file path and the relevant line numbers or range from the diff, plus 1-2 lines of surrounding code for clarity
   - problem statement: one-sentence summary of the issue
   - suggested patch: a concrete code snippet or patch (unified diff or minimal replacement) that can be copy-pasted
   - rationale: 1-3 sentences explaining why the change is needed and what could go wrong if not fixed
   - tests to add or update: exact test names, inputs, and expected assertions (table or list)
4) Likely root causes (ranked): produce 3-6 hypotheses about why the issue exists (ranked by likelihood) with a one-line justification each.
5) Diagnosis: for the top 1-2 root causes produce an expanded diagnosis that maps each to specific lines in the diff and explains the execution/attack/failure path.
6) Fix plan (stepwise): produce an ordered list of actionable steps to remediate, each with:
   - step id
   - change description
   - approximate diff size (LOC) and risk level (low/medium/high)
   - verification action (what test or log to check)
   - rollback criterion (when to revert)
7) Patch suggestions: for each high/major severity comment provide a minimal patch with:
   - file path
   - minimal unified diff (or replacement code block) that keeps scope minimal
   - brief migration notes if schema/contract changes are required
8) Test/verification checklist: a checklist with unit/integration/e2e tests, specific assertions, and exact commands to run locally or in CI. Include test data fixtures if required.
9) Acceptance criteria: clear pass/fail criteria for the PR (what must be true before merging).
10) Risk checks: list the top 5 regressions to watch for after merge and how to monitor them (metrics/logs/alerts).
11) Quick remediation priority list: 1-5 items ordered by impact × ease of fix.

Formatting rules:
- Use bullet lists and numbered steps. Use code blocks for snippets/patches.
- Keep each review comment concise; prefer one change per comment.
- When suggesting code, ensure the snippet compiles/validates with the stated {{language_stack}}.
- Do not assume any files beyond the provided {{pr_diff}}. If necessary context is missing, decline to make behavioral changes and request the specific files or runtime logs.
- Minimize scope: prefer targeted small diffs over broad refactors.
- For security-related items include CVSS-like severity mapping and an exploitability note.
- For concurrency and perf items include expected complexity or contention point and any benchmarks or measurement commands.

Produce the full deliverable in the order specified above. Stop after producing the final checklists and do not append unrelated suggestions.

## Output Format
Output:
  1) Assumptions/Unknowns
  2) Likely root causes (ranked)
  3) Fix plan (steps)
  4) Patch suggestions
  5) Test/verification checklist

Within the grouped review comments portion ensure each comment includes: line context, suggested code snippet/patch, rationale, required severity (blocker/major/minor), and tests to add.

## Guardrails
- Do not assume unseen files or behavior; flag missing files as Unknowns.
- Prefer minimal diffs; avoid scope creep or broad refactors unless explicitly allowed in {{constraints_and_standards}}.
- Do not change public APIs unless API compatibility section authorizes changes and migration notes are included.
- Avoid speculative security claims; state exploitability as "likely / possible / unlikely" with justification.
- If a suggested fix requires a migration or multi-step rollout, include a rollback plan and feature-flag suggestion.
- Never produce fixes that disable logging, remove authentication checks, or hardcode secrets.

## Examples
- Mini example root-cause + fix excerpt:
  - Root cause (example): CORR-1: Null pointer when user object is absent because request handler assumes req.user is non-null.
  - Minimal patch excerpt:
    - file: src/handlers/authHandler.ts
    - patch:
      --- a/src/handlers/authHandler.ts
      +++ b/src/handlers/authHandler.ts
      @@ -42,7 +42,11 @@
       function handleRequest(req, res) {
    -    const userId = req.user.id;
    +    if (!req.user) {
    +      return res.status(401).json({ error: "unauthenticated" });
    +    }
    +    const userId = req.user.id;
       ...
    -Rationale: Prevents a server crash by validating the authenticated user; severity: major; tests: add unit test for unauthenticated request expecting 401.

Variables

Usage Notes

Not for

• • Complete security compliance audits or legal/regulatory attestations (e.g., SOC2, HIPAA certification) — this is a developer-focused review aid, not a compliance report.

• • Binary-only diffs (compiled assets), designer assets, or large monolithic refactors without breaking into smaller reviewable commits.

• • Replacing human reviewers — recommendations must be validated by the code owner and QA/security teams before merge.

Do not include

• • Secrets, private keys, or personal data in the PR diff or logs (never paste secrets into the prompt).

• • Undocumented production credentials or proprietary closed-source dependencies that reviewers cannot access—omit or sanitize them.

• • Requests to fabricate runtime metrics, benchmarks, or security exploit proofs; the template provides guidance, not guaranteed exploits or performance numbers.

PR Review: Targeted Review Comments & Fix Plan (Template)

Turn a provided PR diff into a high-precision engineering-grade review: grouped comments (correctness, security, concurrency, performance, API compatibility, test gaps), ranked root-cause hypotheses, minimal fix plan, patch snippets, and a verification checklist.

Turn this into a working asset in minutes.

Import into Workspace to auto-fill variables, adapt output style, and iterate with OctiAI's prompt editor.

• Auto-fill & personalize from your inputs

• AI-assisted edits: tone, structure, constraints

• Attach context so outputs stay consistent

• Iterate and save versions

What you'll get

Output format

Markdown

Best used when

• When working on template or detailed.

Avoid when

• Complete security compliance audits or legal/regulatory attestations (e.g., SOC2, HIPAA certification) — this is a developer-focused review aid, not a compliance report.

Sign in to save, like, or rate this prompt.

Made for

What to fill in

Use the guidance below to complete each placeholder with the right level of detail.

Repo Name Or Url

Provide the key details needed for this variable.

Pr Diff

Provide the key details needed for this variable.

Language Stack

Provide the key details needed for this variable.

Constraints And Standards

Provide the key details needed for this variable.

Output Format

Provide the key details needed for this variable.

Rules

• Provide the full PR diff/patch as the required input (unified diff or Gerrit/GitHub patch). If the diff is >5k LOC, split into focused chunks and run the prompt per chunk.

• Specify the tech stack (primary language/framework) exactly, e.g., "Node 18 + TypeScript + Express" or "Go 1.20 + Gin" and state coding/security/perf constraints (lint rules, OWASP level, no behavior change, etc.).

• Set desired output format to Markdown (the template is optimized for Markdown). If inputs are missing (diff, language, or constraints), the prompt will list the minimal missing artifacts and stop.

• Optional: attach failing tests, CI logs, or a short incident summary to improve diagnostic accuracy. Expect the model to generate review comments, minimal diffs, and a verification checklist you can copy into a PR review or ticket.

Canonical Examples

Input: Repo: github.com/acme/payments-service. PR diff: adds src/middleware/auth.ts change that parses Authorization header and uses jsonwebtoken.verify but strips Bearer prefix incorrectly and omits audience/issuer checks; missing unit tests. Tech stack: Node 18 + TypeScript + Express. Constraints: small diff only, no public API changes, OWASP: high. Desired output_format: checklist.

Loading result...

Failed to load output.

Top-level: Risk = high → block. Key fixes: strict Bearer parsing, enforce jwt.verify options (aud, iss, algorithms), add unit tests for missing/invalid/malformed tokens, add CI check for token handling.

Why it works: This example demonstrates a common high-impact security/regression pattern (token parsing + verification omitted or partial) and shows how the prompt converts a PR diff into precise review comments, ranked root-cause hypotheses, minimal patch suggestions, and test/verification steps—delivered as a checklist suitable for engineers to apply immediately.

Input: Repo: gitlab.internal/storage-service. PR diff: adds in-memory cache struct simple map access in pkg/cache/cache.go with Get/Set methods; missing mutex and tests. Tech stack: Go 1.20 + net/http; Constraints: small diff, no API change, follow repo lint rules.

Loading result...

Failed to load output.

Top-level: Risk = medium → changes requested. Key fixes: add sync.RWMutex to cache, add unit test with -race, add benchmark and flamegraph instructions.

Why it works: This example portrays a concurrency/data-race class of regression. It shows how the prompt produces targeted code-review comments, root-cause hypotheses, minimal patches to add synchronization, and test steps including race detector and load bench commands—delivered as machine-actionable artifacts engineers can apply.

Works Best With

Best used when you can provide a PR diff + primary tech stack + constraints

• Provide the exact PR diff or unified patch (required).

• Specify the primary language and framework (e.g., "Node 18 + TypeScript + Express", "Go 1.20").

• List constraints and standards (e.g., OWASP level, no public API changes, small diff preferred).

• Include failing logs/tests or runtime config when available to remove unknowns.

• Choose output_format: checklist / stepwise plan / rubric to control structure of deliverable.