Concurrency Code Review Checklist Prompt

Engineering teams standardizing concurrency review practices need a systematic, repeatable checklist that adapts to the specific code change, language, and concurrency primitives involved. This prompt generates a context-specific review checklist with pass/fail criteria, replacing ad-hoc reviewer memory with a structured artifact that can be tracked, audited, and improved over time. The ideal user is a senior engineer or tech lead conducting a pre-merge review for a pull request that touches shared state, locks, channels, async operations, or transaction boundaries.

Use this prompt when your team reviews PRs that modify synchronization logic, introduce new concurrent data structures, or alter goroutine/thread lifecycles. The prompt requires the actual code diff, the target language, and a list of concurrency primitives in play as inputs. It is designed to be wired into a CI/CD pipeline or a code review tool where it can produce a markdown checklist artifact that reviewers work through item by item, checking off each pass/fail criterion before approving the change.

Do not use this prompt as a substitute for runtime race detectors, stress tests, or formal verification tools. The checklist is a review aid, not a correctness proof. It cannot guarantee the absence of race conditions, and it should never be the sole gate for safety-critical or financial transaction code paths. For high-risk changes, always pair the generated checklist with automated race detection under load and a human approval step that verifies each checklist item against the actual code behavior.

The following prompt template is designed to be dropped into your code review pipeline. It instructs the model to act as a systems-level reviewer, analyzing a provided code diff against a set of concurrency primitives and generating a structured, actionable checklist. The template uses square-bracket placeholders that your application must populate before sending the request to the model. The most critical placeholders are [CODE_DIFF], which should contain the unified diff of the change, and [LANGUAGE], which tailors the analysis to language-specific memory models and concurrency constructs.

textCopy
You are a senior systems engineer performing a concurrency-focused code review.
Your task is to analyze the provided code change and generate a structured review checklist.

## Input Context
- **Language:** [LANGUAGE]
- **Change Type:** [CHANGE_TYPE, e.g., bug_fix, new_feature, refactor]
- **Concurrency Primitives Used:** [PRIMITIVES_USED, e.g., mutex, channels, async/await, locks]
- **Risk Level of Change:** [RISK_LEVEL, e.g., low, medium, high, critical]

## Code Diff to Review
```[LANGUAGE]
[CODE_DIFF]

Instructions

1. Identify every section of the diff that touches shared state, synchronization, I/O, or async boundaries.
2. For each identified section, generate a checklist item.
3. Each checklist item must include:
   • Category: [Data Race, Deadlock, Atomicity Violation, Thread Safety, Resource Leak, Correctness]
   • Location: File path and line range from the diff.
   • Check: A specific, pass/fail question the reviewer must answer.
   • Guidance: A brief explanation of what to look for to pass the check.
4. Do not include items for code that is purely algorithmic with no concurrency implications.
5. Group checklist items by category, ordered by risk severity.

Output Schema

Return a JSON object with the following structure: { "review_checklist": [ { "category": "string", "location": "string", "check": "string", "guidance": "string" } ], "risk_summary": "string" }

Constraints

• Only report on code present in the diff. Do not hallucinate issues in unchanged files.
• If no concurrency risks are found, return an empty checklist and a risk_summary stating that.
• Use precise technical language appropriate for a [LANGUAGE] code review.

To adapt this template, your application should first run a static analysis or diff-parsing step to populate [PRIMITIVES_USED] and [CHANGE_TYPE]. This pre-processing prevents the model from guessing and grounds the review in concrete facts. The [RISK_LEVEL] can be set based on the component's criticality or a prior triage step. For high-risk or critical changes, the generated checklist should be treated as an advisory tool; a human reviewer must sign off on each item. Implement a post-processing validation step that parses the JSON output and verifies that every location field references a file path and line range that exists in the original [CODE_DIFF] to catch model hallucinations before they reach the reviewer.

The Concurrency Code Review Checklist Prompt is designed to be integrated into a deterministic software delivery pipeline, not just used as an ad-hoc chat. The primary integration points are a CI/CD system (like GitHub Actions, GitLab CI, or Jenkins) triggered on pull request events, or a code review platform's automation API. The harness must extract the code diff, identify the primary language and changed concurrency primitives, and inject them into the prompt's [CODE_DIFF], [LANGUAGE], and [CONCURRENCY_PRIMITIVES] placeholders. Because concurrency bugs are high-severity and hard to reproduce, the output should be treated as a structured artifact that is attached to the PR as a review checklist, not as a passing or failing CI status on its own.

A robust implementation requires a multi-stage harness. First, a pre-processing stage parses the diff to extract only relevant files (e.g., excluding documentation or config changes) and uses a static analysis tool or simple regex to detect concurrency primitives like synchronized, Lock, go, async, or Mutex. This stage populates the [CONCURRENCY_PRIMITIVES] and [LANGUAGE] fields. Second, the LLM call stage sends the assembled prompt to a capable model (GPT-4o or Claude 3.5 Sonnet are recommended for their structured output reliability). The call must specify a strict JSON schema for the response, matching the checklist structure defined in the prompt's [OUTPUT_SCHEMA]. Third, a validation stage parses the JSON output and runs schema validation, checking that every checklist item has a non-empty id, category, criterion, and pass_fail_guidance. Any malformed response triggers a single retry with a repair prompt that includes the validation error. If the retry also fails, the harness logs the failure and posts a comment on the PR requesting a manual concurrency review, ensuring the pipeline never silently drops a critical safety check.

For high-risk codebases (financial systems, safety-critical services, or multi-threaded data pipelines), the harness should include a human approval gate. After the checklist is generated and validated, it is posted as a PR comment or review summary. The CI pipeline should block the merge until a designated reviewer with concurrency expertise checks a box or applies a label (e.g., concurrency-reviewed). This prevents the checklist from becoming a rubber-stamp artifact. Additionally, log every prompt invocation, including the diff hash, model response, validation status, and reviewer action, to an observability platform. This audit trail is essential for post-incident analysis if a concurrency bug slips through, allowing the team to trace whether the checklist was generated correctly, reviewed adequately, or ignored. Avoid using this prompt on every trivial commit; gate it on changes touching files with known concurrency patterns or directories flagged in a .concurrency-review.yml configuration file to manage cost and reviewer fatigue.