Published: 2026-07-28 | By: Carlos Montiel | Reading time: ~4 minutes
Don't reinvent the prompt every time. These ten are ones I use (or have seen used) every day on real engineering teams, and they're worth more saved in a snippet manager than in your memory.
1. Code review with a severity rubric
The most common mistake when asking a model to review code is not telling it how strict to be. Without that, it mixes style nits with real bugs and the output turns into noise. This prompt separates findings by severity and asks for evidence, not vague opinions.
Review this diff as a senior engineer doing code review.
Report EVERY finding you notice, including ones you have low
confidence in or consider low severity. Don't filter by
importance at this step -- I'll do that afterward.
For each finding include:
- Severity: blocking | important | minor
- Confidence: high | medium | low
- Line and concrete explanation (not "this could be improved")
- If applicable, the suggested fix in one line
If you find nothing, say so explicitly. Don't invent
observations to seem thorough.
Diff:
{diff}
This pattern -- asking for full coverage and leaving filtering for later -- is key on recent models (Sonnet 5, Opus 4.7/4.8): when the prompt says "only report what's important," the model obeys literally and ends up hiding real bugs it judged "minor." Separating finding from filtering recovers that recall.
2. Root cause of a stack trace without full context
When you paste a stack trace to a model, the temptation is to ask "fix it." Better: ask for a structured diagnosis first, because the obvious fix often attacks the symptom, not the cause.
Analyze this stack trace and the relevant code. Before proposing
a fix, answer:
1. What's the most likely root cause? (not the symptom)
2. What other hypotheses did you consider and why did you rule them out?
3. What additional evidence would confirm or refute your main
hypothesis? (logs, line of code, variable value)
Only after that, propose the minimal necessary fix.
Stack trace:
{trace}
Relevant code:
{code}
3. Commit message generator from a diff
Useful as a pre-commit hook or manual command. The key is asking it to explain the "why," not narrate the diff line by line.
Write a commit message for this diff following Conventional
Commits (feat/fix/refactor/chore/docs).
Title: max 72 characters, imperative mood.
Body (optional, only if the change isn't trivial): 1-3 lines
explaining WHY the change was made, not which files were
touched -- the diff already shows that.
Don't include explanations outside the commit message.
Diff:
{diff}
4. Test generator from a function
Ask for explicit edge cases instead of letting the model improvise generic coverage.
Generate unit tests for this function using {framework}.
Must include:
- The happy path
- At least 2 edge cases (empty values, nulls, numeric limits)
- An expected-error case (exception or error return value)
- If the function has side effects, a test that verifies them
Don't generate mocks for dependencies that don't exist in the
code shown. If you need more context to mock something, say so
instead of inventing the interface.
Function:
{code}
5. Complex SQL query explainer
For onboarding or for understanding 200-line legacy queries.
Explain this SQL query at three levels:
1. One sentence: what it returns, in business terms.
2. Step by step: what each CTE/subquery does, in logical
execution order (not the order it's written in).
3. Risks: are there joins that could multiply rows, badly
partitioned window functions, or filters applied after an
aggregate that should go before it?
Query:
{sql}
6. Incident postmortem from logs and timeline
Using this incident's information, write a postmortem in
blameless format.
Structure:
- Summary (2 lines, what happened and measurable impact)
- Timeline (time, event, who/what detected it)
- Root cause (technical, not "human error" as the final cause --
ask yourself what system or process allowed that human error)
- What went well in the response
- Follow-up actions, each with an owner and type:
prevention | detection | mitigation
Incident data:
{timeline_and_logs}
7. Endpoint documenter from code
Generate OpenAPI-style documentation for this endpoint from
the code (don't invent fields that don't exist in the handler
or the validation schema).
Include: method, route, parameters with type and whether
required, possible response codes with their meaning, and a
request/response example.
If the code doesn't validate an obvious error case (e.g. doesn't
check authentication), flag it as a separate note, don't
document it as if it existed.
Endpoint code:
{code}
8. Changelog for non-technical users
Translates technical commits into product language -- useful for release notes going out to customers.
Convert this list of commits into a changelog for non-technical
end users.
Rules:
- Group by category: New | Improved | Fixed
- Each line describes the IMPACT for the user, not the
implementation ("You can now export reports as PDF,"
not "added /export/pdf endpoint")
- Omit purely internal changes (refactors, tests, CI)
unless they fix a visible bug
Commits:
{list_of_commits}
9. Onboarding to an unfamiliar module
When you inherit undocumented legacy code, this prompt generates a quick mental map.
Act as an engineer who needs to understand this module for
the first time to make an urgent change.
Answer:
1. What is this module's main responsibility?
2. What other modules depend on it, and what are its own dependencies?
3. What parts of the code look fragile or have obvious technical
debt (generic names, very long functions, missing error
handling)?
4. If I had to add {new_feature}, where would you start and
what would you touch most carefully?
Module code:
{code}
10. Ambiguous requirements to acceptance criteria translator
For when a ticket arrives as a single vague line and you need to turn it into something implementable.
Here's a ticket exactly as the user/PM wrote it. Convert it
into verifiable acceptance criteria.
If there's real ambiguity (not just minor missing detail), list
it as open questions at the end -- don't resolve it by assuming,
because a wrong assumption here costs more than a question.
Original ticket:
{ticket}
Output format:
- Acceptance criteria (list, each verifiable with a test)
- Out-of-scope cases (explicitly, to avoid scope creep)
- Open questions (only if they're blocking)
Save these ten in your snippet manager with clear variables. The five-minute investment adjusting them to your stack pays for itself the first week.