Unstructured AI code reviews produce noise. The model identifies every variable naming inconsistency, every opportunity to use a list comprehension, every place where a docstring could be added — and buries the actual security vulnerability or race condition under 20 style comments. The sinc review template fixes this by specifying review depth, focus areas, severity levels, and explicitly banning style nitpicks. You get 5 actionable findings instead of 30 mixed-priority comments.
This template is configured for a security-focused review of authentication code — the highest-stakes review type where missing a vulnerability has real consequences:
{
"formula": "x(t) = Σ x(nT) · sinc((t - nT) / T)",
"T": "specification-axis",
"fragments": [
{
"n": 0,
"t": "PERSONA",
"x": "You are a senior security engineer doing a pre-merge review. You think like an attacker, not a teacher. You look for vulnerabilities that could be exploited in production, not style improvements. You rate severity honestly — if something is low risk, say so."
},
{
"n": 1,
"t": "CONTEXT",
"x": "This is a password reset flow in a production web app. It handles generating reset tokens, sending emails, and validating tokens at redemption time. The code is being reviewed before merging to main. The service handles 50,000 users."
},
{
"n": 2,
"t": "DATA",
"x": "[paste the code to review here]\n\nStack: Python 3.11, FastAPI, SQLAlchemy, itsdangerous for token signing. Token expiry: 1 hour. Database: PostgreSQL."
},
{
"n": 3,
"t": "CONSTRAINTS",
"x": "Do NOT comment on code style, naming conventions, or formatting — those are handled by the linter. Do NOT suggest docstrings. Do NOT flag issues that the linter would catch. Only report findings that could cause: (1) security vulnerabilities, (2) data corruption, (3) authentication bypass, (4) token enumeration attacks, (5) race conditions that affect correctness. Rate each finding: CRITICAL (block merge), HIGH (fix before next release), MEDIUM (fix in next sprint), LOW (optional). Skip LOW findings unless there are fewer than 3 higher-severity findings."
},
{
"n": 4,
"t": "FORMAT",
"x": "Numbered findings only. Each finding: [SEVERITY] — file:line — issue description (1-2 sentences) — specific exploit scenario — fix recommendation (1-2 sentences). Maximum 8 findings. If code is clean, say 'No critical or high findings. Code is safe to merge.' Do not add preamble."
},
{
"n": 5,
"t": "TASK",
"x": "Review the password reset code for security vulnerabilities, data integrity risks, and authentication bypass vectors."
}
]
}When a code review prompt includes a severity rating framework, the model applies it as a filter before generating output. Without it, all findings are implicitly equal — a missing docstring gets the same weight as a timing attack vulnerability. With it, the model categorizes each finding before reporting it, and your CONSTRAINTS can suppress low-priority categories entirely.
"Skip LOW findings unless there are fewer than 3 higher-severity findings" is a triage rule that keeps the review actionable. A 30-item review is ignored. A 5-item review with clear severity ratings gets addressed in the current sprint.
Code review tip: Tune the PERSONA for the review type. "Security engineer who thinks like an attacker" produces security findings. "Performance engineer looking for N+1 queries and missing indexes" produces database performance findings. "API designer checking consistency and backwards compatibility" produces API contract findings. The same code, different PERSONA, different findings. Use the persona to focus the review lens.
Review this code for my password reset feature. Point out any issues you find. [code pasted]
PERSONA: Security engineer, thinks like attacker, rates severity honestly.
CONSTRAINTS: No style/naming/docstring comments. Only security, data corruption, auth bypass, race conditions. Rate CRITICAL/HIGH/MEDIUM/LOW. Max 8 findings.
FORMAT: Numbered findings with severity + exploit scenario + fix. No preamble.
The raw prompt produces 22 findings: 3 security issues, 14 style comments, 5 docstring suggestions. The structured prompt produces 5 findings: 1 CRITICAL (timing attack on token comparison), 2 HIGH, 2 MEDIUM. The CRITICAL issue would have been buried in the noise without the structured format.
Try AI Transform — Structure Your Review Prompt Free