AI Prompts for Developers

Pre-review sweep: your own PR through a security-and-edge-case lens

The PR is 'done'. Run the pre-review sweep so human reviewers spend their attention on design — not on nits and the missed null check.

You are a staff engineer reviewing a pull request. I will paste the diff and its context. Produce:

A) REVIEW TABLE — columns: file/line reference, severity (blocker / major / nit), category (correctness, security, performance, readability, tests), the issue in one sentence, and a suggested fix as a concrete code change.

B) EDGE-CASE LIST — inputs and states the diff does not handle: empty, null, concurrent access, oversized input, malformed input, permission-denied.

C) VERDICT — approve or request-changes, plus the 2 highest-risk lines in the diff and why.

Inputs: [PASTE DIFF] · [WHAT THE CHANGE DOES + WHY] · [LANGUAGE/FRAMEWORK + TEAM CONVENTIONS]

Rules: Do not invent code that is not in the diff — reference only pasted lines. Any claim about behavior you cannot see (callers, config, upstream state) must be marked "verify in repo". Never echo secrets or keys, and do not include proprietary code beyond what I pasted.

Security-first PR review: a diff read that hunts the bug class, not the typo

You're reviewing a big PR and low on time. Get a structured read that prioritizes correctness and security over style nits.

You are a staff engineer reviewing a pull request — a review aid whose findings I will verify, not merge blindly.

Produce:

A) RISK SUMMARY — a one-line verdict (safe / needs-changes / blocked) and the single biggest concern.

B) FINDINGS TABLE — each issue: file/area, severity (blocker / major / minor / nit), the specific concern, and a suggested fix — sorted severity-first, with security and correctness above style.

C) MISSING TESTS — the behaviors and edge cases this diff changes that the tests don't cover.

D) QUESTIONS FOR THE AUTHOR — the 2-3 things I should ask before approving, where intent isn't clear from the diff.

Inputs: [PASTE THE DIFF OR KEY FILES] · [WHAT THE PR IS SUPPOSED TO DO] · [LANGUAGE / FRAMEWORK] · [ANYTHING RISKY I ALREADY SUSPECT]

Rules: Do not claim a line is buggy without saying why; if you're unsure, list it as a question, not a finding. Don't invent APIs or behavior not visible in the diff. Keep proprietary source out of consumer AI tools per your employer's policy. This drafts the review; you verify every finding before you approve. Do not invent facts, numbers, or details you weren't given.

Root-cause interrogation: a hypothesis ladder from a bug report

Prod bug, vague repro, clock ticking. Structure the investigation before you start changing code at random.

You are a senior engineer running a structured root-cause investigation. I will paste the symptoms and every piece of evidence I have. Produce:

A) HYPOTHESIS LADDER — 5 ranked hypotheses. For each: the mechanism, which pasted evidence supports or contradicts it, and the cheapest discriminating test (a log line to add, a git bisect range, a feature-flag toggle, a minimal repro).

B) EVIDENCE GAPS — what I have not given you that would most change the ranking, in priority order.

C) PREVENTION — run 5-whys on the top hypothesis and name the class-level fix (test, lint rule, alert, type change) that prevents the whole category from recurring.

Inputs: [SYMPTOM + WHEN FIRST SEEN] · [PASTE LOGS / STACK TRACE / RECENT DIFFS] · [ENVIRONMENT + RECENT DEPLOYS]

Rules: Do not invent stack frames, log lines, or code behavior not in my paste — every hypothesis must cite the evidence line it rests on, and pure speculation must be labeled as such. Verify the discriminating test's result before acting on any hypothesis. Strip credentials and user PII from anything you echo back.

Stack-trace triage: from a wall of errors to the two likeliest root causes

Production is throwing and the trace is a mess. Narrow it to the two most probable causes and the fastest way to confirm each.

You are a senior engineer triaging a failure — a reasoning aid whose hypotheses I will test, not trust.

Produce:

A) READ — a plain-English restateme

Design doc skeleton with the alternatives you'll actually be asked about

New system or big refactor. Draft the design doc with real alternatives and failure modes before the review meeting drafts it for you.

You are a principal engineer drafting a design document. I will describe the problem and constraints. Produce:

A) DOC SKELETON — context and problem,

RFC skeleton: pressure-test the design before you write the code

You're about to build something non-trivial. Draft an RFC that names the tradeoffs and the rejected alternatives, so review is real.

You are a principal engineer drafting an RFC skeleton for a technical design I will own and complete.

Produce:

A) PROBLEM + CONSTRAINTS — the proble

Test-plan generator: risk-ranked cases from a diff or spec

Feature complete, coverage thin. Generate the test plan ranked by what would actually hurt in production.

You are a test engineer designing a risk-based test plan. I will paste the spec or the diff. Produce:

A) TEST MATRIX — columns: behavior under test,

Edge-case hunt: the failure inputs your happy-path tests will miss

Your tests pass but you don't trust them. Enumerate the boundary and failure cases that the happy path never touches.

You are a test engineer building an edge-case and failure-mode inventory for a function or feature I'll implement.

Produce:

A) BEHAVIOR RESTATEMENT

Toil audit: find the hours a week your workflow is leaking

You suspect the week disappears into builds, reviews, and context switches. Audit it and get an automation plan with paybacks.

You are a developer-productivity engineer auditing one engineer's week. I will paste a work log. Produce:

A) TOIL TABLE — columns: recurring task, fr

Ticket breakdown: split an epic into shippable, independently-testable slices

You have a vague epic and a sprint to fill. Break it into small tickets that each ship value and can be tested alone.

You are a tech lead breaking a large piece of work into implementable tickets for my review.

Produce:

A) SLICE PLAN — the epic split into 4-8 ticket