Synchronization Primitive Misuse Detection Prompt

This prompt is designed for systems engineers and platform teams who need to detect incorrect usage of synchronization primitives—mutexes, semaphores, condition variables, and barriers—in code changes. The core job-to-be-done is to receive a code snippet or diff and produce a structured misuse report that identifies specific bugs, rates their severity, and provides the correct usage pattern for the target language. It is intended to be embedded in pre-merge code review pipelines, static analysis triage workflows, or as a dedicated step in a concurrency bug detection harness where a human reviewer needs a reliable, structured second opinion before code reaches production.

The prompt assumes the input code is syntactically valid for the target language and that the reviewer requires a report with concrete findings, not a general code quality assessment. It is optimized for detecting double-lock risks, signal-before-wait bugs, incorrect unlock patterns (e.g., unlocking a mutex from a thread that does not own it), and spurious wakeup vulnerabilities. The output is expected to be a structured JSON report containing a list of findings, each with a severity rating, the offending code location, an explanation of the misuse, and the correct synchronization pattern. For high-risk domains, the prompt's output should be treated as a triage aid, not a final verdict; a human reviewer must confirm findings before blocking a merge or filing a bug.

Do not use this prompt for general code style review, performance profiling, or security vulnerability assessment outside of synchronization primitive misuse. It is not designed to reason about algorithmic correctness, business logic errors, or memory safety issues unrelated to concurrency control. If the input code does not contain any synchronization primitives, the prompt will return an empty finding set, which is the expected behavior. Before integrating this prompt into a CI/CD pipeline, validate its output against a golden dataset of known concurrency bugs and benign code samples to calibrate your acceptable false positive rate and ensure the severity ratings align with your team's risk tolerance.

This prompt template is designed to be dropped into your code review pipeline, IDE, or CI harness. It expects a code snippet, the target language, and a set of synchronization primitives to inspect. The placeholders let you control the scope of analysis, the output format, and the risk tolerance. Adapt the [CONSTRAINTS] block to match your team's coding standards, and replace [OUTPUT_SCHEMA] with the exact JSON schema your review tooling expects. The template is self-contained: a developer can paste it into a chat interface with a code block and get a structured misuse report without needing the rest of the playbook.

textCopy
You are a systems concurrency reviewer. Analyze the provided code for synchronization primitive misuse.

## Input
[CODE]

## Target Language
[LANGUAGE]

## Primitives to Inspect
[PRIMITIVES]

## Constraints
- Flag only confirmed or highly likely misuse patterns. Do not flag correct but unusual usage.
- For each finding, cite the exact line or line range.
- If the code is correct, return an empty findings list.
- [CONSTRAINTS]

## Output Schema
Return a JSON object matching this schema exactly:
[OUTPUT_SCHEMA]

## Examples
[EXAMPLES]

## Risk Level
[RISK_LEVEL]

To adapt this template, start by defining [PRIMITIVES] as a comma-separated list: mutex, semaphore, condition_variable, barrier. Set [RISK_LEVEL] to high if you want the model to flag even subtle anti-patterns like spurious wakeup vulnerabilities, or medium for a focus on clear-cut bugs like double-lock attempts. The [OUTPUT_SCHEMA] should be a strict JSON schema including fields like findings, severity, line_range, misuse_type, explanation, and fix_suggestion. If you have known good and bad examples from your codebase, add them to [EXAMPLES] as few-shot pairs to calibrate the model to your team's conventions. After generating the report, always validate the JSON structure and run the findings through a human reviewer when the code touches production data paths or security boundaries.

This prompt is designed to operate as a pre-merge analysis gate in a CI/CD pipeline or as an on-demand review tool in a developer's IDE. The core integration pattern is: extract a code diff or file content, inject it into the [CODE_INPUT] placeholder along with the [LANGUAGE] and [PRIMITIVE_TYPES] constraints, run the model, and parse the structured JSON output for actionable findings. Because concurrency bugs are high-severity and hard to reproduce, the harness must treat model output as advisory evidence rather than a blocking verdict—every finding should be linked to a specific line range and require human confirmation before a PR is blocked.

Validation and retry logic is critical. The prompt requests a strict JSON array of finding objects with fields like severity, line_range, primitive, misuse_type, and fix_suggestion. The harness must validate that the response parses as valid JSON, that each finding contains the required fields, and that line_range values map to actual lines in the input code. If validation fails, implement a single retry with the error message appended to the prompt context. If the retry also fails, log the raw output and surface it for manual review rather than silently dropping findings. For high-risk code paths (e.g., payment processing, safety-critical systems), route all `severity:

critical"` findings to a human approval queue before the PR can merge."

Model choice and tool integration should match the risk profile. For routine PR review, a fast model like Claude 3.5 Haiku or GPT-4o-mini works well with a temperature of 0.1 to keep output deterministic. For security-sensitive or kernel-level code, use a more capable model (Claude 3.5 Sonnet or GPT-4o) and consider pairing the prompt with a static analysis tool like ThreadSanitizer or Helgrind—use the model to interpret and deduplicate the tool's raw output rather than scanning code from scratch. If your codebase has runtime lock tracing data, inject it into the [RUNTIME_TRACE] placeholder to ground the model's analysis in observed behavior. Log every invocation with the prompt version, model, input hash, and output findings to enable prompt regression testing and audit trails.

What to avoid in production: Do not use this prompt as the sole gate for blocking merges without human review. Do not skip validation of line ranges—models can hallucinate line numbers. Do not run on entire repositories in a single call; chunk by file or diff to stay within context windows and keep findings localized. Do not ignore false positive feedback—maintain a suppression list of known false-positive patterns and feed them back into the prompt's [KNOWN_FALSE_POSITIVES] placeholder to improve precision over time. Start with a shadow mode deployment where findings are logged but not blocking, calibrate against your team's manual review accuracy, and only then promote to a soft gate with human escalation for critical findings.