Quality Prompts

Quality prompts break symmetry: different stance, different agent, or explicit enumeration. Don't ask the authoring session to "make sure it's fine." Technique: Quality & Review Prompts, Reviewing AI PRs, Reviewing AI Tests.

Code review

Adversarial review of a diff against a spec — findings only.

Inputs: <diff ref>, <spec path>, <severity dimensions>

Review this change as a skeptical staff engineer. You did not write it.

Diff: <diff ref>
Spec: <spec path>

Review in order, worst first:
1. Spec compliance — each acceptance criterion: met / not met / unclear
2. Correctness — edge cases, error paths, concurrency
3. Scope creep — files/behavior not required by the spec
4. Blast radius — callers not updated
5. Tests — which criteria lack tests; which tests would pass if broken

Rules:
- No praise, no style nits, no summary of what the code does.
- Each finding: severity (blocker/major/minor) + file:line + why.
- If nothing ≥ major, state what you checked and the evidence.

Do not fix the code unless I ask.

Expected output: ordered findings with severities; or evidence-backed "no major issues."

Evaluate: Findings cite lines. Spec criteria are enumerated. "Looks good" alone is a failed review.

Variations:

• Restrict to security+correctness only.
• Output as a PR comment checklist.

Security review

Threat-focused review of a change or subsystem.

Inputs: <diff or path>, <trust boundaries>, <data classes>, <authz model>

Security review — find exploitable issues, not style.

Target: <diff or path>
Trust boundaries: <trust boundaries>
Data classes: <data classes>
Authz model: <authz model>

Hunt specifically for:
- Authn/authz gaps, IDOR, privilege escalation
- Injection (SQL/command/template), unsafe deserialization
- Secret leakage (logs, errors, client bundles)
- SSRF, path traversal, open redirects
- Insecure defaults, missing rate limits on sensitive routes
- Multi-tenant isolation breaks

For each finding: severity, exploit sketch, affected path, fix direction.
Ignore theoretical issues that don't apply to this stack.
Do not rewrite the feature — report only.

Expected output: exploit-oriented findings with fix direction; explicit "checked X, clean" for major categories.

Evaluate: Exploit sketches are plausible in your deployment. No generic OWASP essay. Tenancy/authz covered if relevant.

Variations:

• Dependency/supply-chain pass only.
• Focus on a single new endpoint.

Performance review

Find real hot paths and complexity bombs, not micro-optimizations.

Inputs: <diff or path>, <SLOs or budgets>, <expected volume>, <profiling evidence if any>

Performance review of: <diff or path>
SLOs/budgets: <SLOs or budgets>
Expected volume: <expected volume>
Evidence: <profiling evidence if any>

Identify:
1. Algorithmic / query complexity risks (N+1, unbounded scans, sync
   work on request path).
2. Allocations / payloads that blow up at stated volume.
3. Missing pagination, timeouts, backpressure.
4. Caching opportunities that are safe (include invalidation).
5. What to measure next (specific metrics/probes).

Severity by user impact at <expected volume>, not by cleverness.
No "use a faster language" advice. Do not implement fixes yet.

Expected output: ranked perf risks + measurement plan.

Evaluate: Risks tied to volume/SLO. N+1 and unbounded work called out if present. Fix ideas are local.

Variations:

• Frontend: bundle size + render path only.
• Require explain plans for touched queries.

Second-agent review

Fresh session review — author agent must not be the reviewer.

Inputs: <branch or PR>, <task brief>, <known sensitive areas>

You are a second agent. You have no memory of implementing this.

Review branch/PR: <branch or PR>
Original task brief: <task brief>
Sensitive areas: <known sensitive areas>

Process:
1. Read the brief, then the diff, then the tests.
2. Attempt to break the acceptance criteria mentally; list attempts.
3. Report disagreements with the implementation's implicit decisions.
4. Verdict: approve / request changes / block — with reasons.

Do not chat with the authoring agent. Do not "collaborate on a fix"
unless I start a new task for that.

Expected output: independent verdict with break attempts and decision disagreements.

Evaluate: Reviewer didn't rubber-stamp. Implicit decisions are named. See Agent Roles.

Variations:

• Use a subagent with read-only permissions.
• Blind review: hide the author summary; give only spec + diff.

Test generation

Behavior tests with an explicit mock policy.

Inputs: <module path>, <public contract>, <mock policy>, <behaviors to cover>

Write behavior tests for <module path>.

Public contract under test: <public contract>
Mock policy: <mock policy>
Behaviors to cover (one describe each):
<behaviors to cover>

Rules:
- Assert observable results, not internal call counts.
- For each behavior: happy path + one negative case.
- If you discover questionable current behavior, pin it and list under
  "questionable" — do not "fix" behavior in this task.
- Match existing test utilities and file layout.

Do not refactor production code except for test seams I approve first.

Expected output: behavior-focused tests; questionable list if any.

Evaluate: Mentally break the code — would a test fail? Mocks don't swallow the unit under test. See Reviewing AI Tests.

Variations:

• Property-based tests for pure logic.
• Characterization suite for legacy (Maintenance).

Attack the solution

Author or sibling agent tries to break its own (or another's) solution.

Inputs: <target path or diff>, <threat goals>, <in-scope assets>

Attack this solution. Your job is to make it fail.

Target: <target path or diff>
Threat goals: <threat goals>
In-scope assets: <in-scope assets>

Produce:
1. Attack ideas ranked by likelihood of success.
2. Concrete reproduction steps (commands/requests/payloads).
3. Which tests are missing that would have caught each attack.
4. Minimal fixes (directional) — do not implement unless asked.

Be adversarial. "Looks secure" is not an acceptable conclusion without
listing attacks you attempted and why they failed.

Expected output: ranked attacks, repro steps, missing tests, fix directions.

Evaluate: At least one attack is specific (payload/command). Missing tests are actionable.

Variations:

• Chaos: kill dependencies mid-request.
• Concurrency: double-submit / race on the write path.

AI PR review (3-pass)

Structured three-pass review for agent-authored PRs.

Inputs: <PR ref>, <spec path>, <risk tier>

Perform a 3-pass review of AI-authored PR <PR ref>.
Spec: <spec path>
Risk tier: <risk tier>

Pass 1 — Intent: Does the PR match the spec? List criteria met/unmet.
Pass 2 — Correctness: Trace critical paths; note error handling gaps,
         data integrity, authz.
Pass 3 — Operability: tests quality, observability, rollback, docs
         touched, dangerous defaults.

Output a single report with three sections and a final merge
recommendation: merge / fix-forward / reject.
For risk tier high: require human confirmation checklist at the end.

No code changes in this task.

Expected output: three-section report + merge recommendation (+ human checklist if high risk).

Evaluate: Passes are distinct. Unmet criteria aren't buried. Recommendation matches findings. See Reviewing AI PRs.

Variations:

• Split passes across three subagents.
• Add Pass 0: secret scan / dependency diff.

Type / lint fix without behavior change

Clear type and lint errors without altering runtime behavior.

Inputs: <check command>, <paths>, <forbidden refactors>

Fix typechecker/linter failures only.

Command: <check command>
Scope: <paths>
Forbidden: <forbidden refactors>

Rules:
- Behavior must not change — no logic edits except to satisfy types
  correctly (prefer narrowing, guards, correct types over `as any`
  or `@ts-ignore` unless pre-existing and unavoidable — then isolate).
- Do not reformat unrelated files.
- Do not "clean up" while you're here.
- After fixes, re-run <check command> and relevant unit tests.

Summarize each fix class (e.g., "added null guard in X") in the end notes.

Expected output: green checks; minimal diff; fix-class summary.

Evaluate: git diff is types/lint only. Tests still pass. No drive-by renames.

Variations:

• Allow eslint --fix only; manual for type errors.
• Forbid any entirely; fail if that's the only path.

Flaky test quarantine and diagnosis

Isolate flaky tests and find the real cause — don't mute assertions.

Inputs: <flaky test IDs>, <repro command>, <CI vs local difference>

Diagnose flaky tests: <flaky test IDs>
Repro: <repro command>
CI vs local: <CI vs local difference>

Do:
1. Reproduce locally with stress (repeat / random order / parallel).
2. Identify root cause class: time, order, shared state, network, race.
3. Propose a real fix (determinism) — not `retries: 3` as the fix.
4. If quarantine is needed temporarily, quarantine with a tracking
   comment/ticket reference and a failing reproduction note.

Do not weaken assertions to make the suite green.

Expected output: root cause class, deterministic fix proposal, optional tracked quarantine.

Evaluate: Cause is named. Fix restores determinism. Assertions intact.

Variations:

• Focus on parallel test pollution only.
• Require a minimal standalone repro file.

Related

• Quality & Review Prompts — pattern rationale
• Reviewing AI PRs — PR playbook
• Testing AI Code — verification workflow
• Reviewing AI Tests — audit generated suites
• Verification Strategy — what "done" means
• Quality Gates — automate the bar these prompts check