Best AI Prompts for Engineers

AI summary

Seven AI prompts for engineers who already use Claude Code, ChatGPT, or Cursor but want the structure to stop accepting glib outputs: bug triage, self-review of a PR, architecture decision docs, test-coverage audits, refactor planning, incident post-mortems, and onboarding doc generation. Built to make AI a tighter collaborator, not a replacement.

Prompt 1

Bug Triage from a Stack Trace

You hit an error you have not seen before. Most engineers paste the stack trace and ask “what’s wrong?” This prompt gets a more useful answer.

I am hitting this error in [LANGUAGE / FRAMEWORK]:

```
[PASTE FULL STACK TRACE]
```

The code that triggered it:

```
[PASTE THE RELEVANT CODE BLOCK]
```

What I was trying to do:

[ONE SENTENCE]

Do the following:

1. NAME THE FAILURE: what category of error this is and the most likely root cause given the trace.
2. THREE HYPOTHESES: rank the three most likely explanations, with the evidence for each.
3. THE DIAGNOSTIC: the single command, log line, or test I should run to confirm hypothesis 1.
4. THE FIX (if hypothesis 1 is right): the smallest change that would resolve it.
5. THE WIDER PROBLEM: if the root cause suggests a broader design issue, name it.

Do not solve the problem by rewriting half my code. Pinpoint the bug; the smallest fix wins.

When to use: Any time you have hit a stack trace twice without solving it. · Best model: Claude Code (CLI) is built for this. Claude Sonnet works for one-off web pasting.

Prompt 2

Code Review on My Own PR

Before you ask a teammate to review your PR, run it through this prompt. The teammate’s time becomes feedback on what AI cannot catch, not basic cleanup.

Here is the diff for a PR I am about to send for review:

```diff
[PASTE FULL DIFF or paste the changed files]
```

The purpose of the PR in one sentence:

[GOAL]

Review this as if you were the most senior engineer on my team. Specifically:

1. CORRECTNESS: any logic that does not match the stated goal.
2. EDGE CASES: inputs or states the code does not handle.
3. NAMING: variables, functions, or files that obscure what they do.
4. ARCHITECTURE: anything that would be easier to maintain if structured differently.
5. TESTS: tests that should exist that do not, or tests that test the wrong thing.
6. DEAD WEIGHT: code that is unused, defensive without reason, or could be deleted.

Do not rewrite the PR. Point out the issues. For each one, give the smallest change that would address it.

Be direct. I want the review my best teammate would give if they were not being polite.

When to use: Right before “Ready for review.” · Best model: Claude Code is best because it can read the actual files. Claude Sonnet works for paste-based review of small diffs.

Prompt 3

Architecture Decision Drafter

Before you write the ADR or RFC, this prompt produces the structured argument so you spend writing time on the part that matters, not the boilerplate.

I need to write an architecture decision record (or design doc) for:

[ONE-SENTENCE PROBLEM STATEMENT]

The context:

[2-3 PARAGRAPHS: existing system, constraints, what is changing, why now]

Options I am considering:

[LIST 2-4 OPTIONS]

My current leaning:

[OPTION X, IF YOU HAVE ONE]

Produce the doc with:

1. CONTEXT: rewrite my context in cleaner prose, 200-300 words.
2. OPTIONS: for each option, the strongest case for and against it, with the trade-off named explicitly.
3. RECOMMENDATION: if my leaning is well-supported, state it clearly. If the trade-offs suggest a different choice, say so and explain why.
4. CONSEQUENCES: what becomes hard, what becomes easy, what breaks if we are wrong.
5. WHAT TO REVISIT: the specific signal that would tell us to reconsider.
6. WHAT IS NOT IN SCOPE: explicit list of adjacent decisions this doc does not address.

Do not advocate beyond what the trade-offs support. If the options are roughly equivalent, say so.

When to use: Before any decision that will outlast the next teammate’s tenure. · Best model: Claude Sonnet or Opus. The discipline about “not advocating beyond the trade-offs” is what makes the doc useful.

Prompt 4

Test Coverage Audit

Your test suite passes. That does not mean the code is tested. This prompt finds the gaps before they become production incidents.

Here is the code under review:

```
[PASTE THE MODULE / FILE]
```

Here is the existing test file for it:

```
[PASTE EXISTING TESTS or say NO TESTS YET]
```

Audit the coverage:

1. PATHS NOT COVERED: branches and conditionals the existing tests do not exercise.
2. INPUT CLASSES NOT COVERED: types of input (empty, null, large, malformed, boundary) not tested.
3. ERROR CASES NOT COVERED: failures and exceptions the code can raise that no test checks.
4. INTERACTIONS: integration points (DB, network, file system) where the unit tests pass but the integration would not.
5. THE TEST I WOULD WRITE FIRST: based on production risk, the one test most worth adding next.

Do not output the test code itself. Identify the gaps. I will write the tests once I know what is missing.

When to use: Before merge on any change touching critical-path code. · Best model: Claude Code (reads the actual codebase). Claude Sonnet for small modules in paste form.

Prompt 5

Refactor Plan Without Rewrite

You have a 600-line file that has grown ugly. The temptation is to rewrite. This prompt produces a refactor plan that ships in 4 PRs instead of 1 hero PR that never lands.

Here is the file I want to refactor:

```
[PASTE FILE]
```

What about it bothers me (be specific):

[YOUR PAIN POINTS: "function does 5 things", "types are too loose", "hard to test", etc.]

The constraints:

- I cannot rewrite from scratch (no full-rewrite PRs).
- I need to keep the test suite passing at every step.
- Reviewers should be able to read each PR in 15 minutes.

Produce a 4-step refactor plan where each step is its own small PR:

1. STEP 1: the smallest no-behavior-change cleanup that improves readability.
2. STEP 2: the next change, building on step 1, still no behavior change.
3. STEP 3: the structural change (extract a class, split a module, change a type).
4. STEP 4: the cleanup pass that removes dead code or simplifies now-redundant abstractions.

For each step, describe what changes and why. Do not write the actual code.

At the end, name the one step where bugs are most likely to slip in, and the specific test to add as a safety net.

When to use: Before opening a refactor PR. · Best model: Claude Sonnet or Opus. The discipline about “no full rewrite” is what makes the plan landable.

Prompt 6

Production Incident Post-Mortem Drafter

Post-mortems get written under deadline, exhausted, by the person closest to the failure. The result is often defensive. This prompt structures the doc so it can actually serve as a learning artifact.

We had a production incident. Details:

WHAT HAPPENED: [BRIEF SUMMARY]
IMPACT: [WHO WAS AFFECTED, FOR HOW LONG]
TIMELINE: [EVENT BY EVENT, INCLUDING DETECTION, RESPONSE, MITIGATION, RESOLUTION]
ROOT CAUSE (technical): [WHAT BROKE]
WHY THE ROOT CAUSE WAS POSSIBLE (process / design): [WHAT LET IT HAPPEN]
WHAT WE TRIED THAT DID NOT WORK: [DEAD ENDS]
WHAT FINALLY WORKED: [THE FIX]

Draft a blameless post-mortem with:

1. SUMMARY: 2-3 sentences for someone reading only the headline.
2. TIMELINE: rewrite mine in a clean format with timestamps and roles, not names.
3. ROOT CAUSE: factual technical cause and the contributing factors.
4. WHAT WENT WELL: parts of the response that worked.
5. WHAT DID NOT GO WELL: where detection, escalation, or recovery was slower than ideal.
6. ACTION ITEMS: 3-5 concrete items with an owner-role (not a name) and a category (prevent / detect / respond / recover).
7. THE QUESTION TO REVISIT: the one underlying assumption this incident challenged.

Do not assign blame to individuals. Do not soften the technical analysis to spare anyone.

When to use: Within 48 hours of an incident closing. · Best model: Claude. The blameless-but-direct tone is hard to maintain and Claude is the most disciplined about it.

Prompt 7

Onboarding Doc Generator

Your new hire needs to ramp on a service. The README is two years old. This prompt drafts what the README should be, based on the code itself.

I need to onboard a new engineer to this service:

SERVICE NAME: [NAME]
WHAT IT DOES (in one sentence): [PURPOSE]
KEY FILES OR ENTRY POINTS:

[PASTE THE TOP-LEVEL CODE STRUCTURE OR THE 2-3 MOST IMPORTANT FILES]

DEPENDENCIES (external systems, queues, databases): [LIST]
RUNBOOK / ONCALL CONTEXT (links to existing playbooks if any): [LINKS OR SUMMARY]

Draft an onboarding doc with:

1. WHAT THIS SERVICE DOES: one paragraph, plain English, no jargon a new hire would not know.
2. HOW IT FITS: what calls it, what it calls, in one diagram I can copy into a tool.
3. THE FIVE THINGS TO READ FIRST: code paths or files, in suggested order.
4. THE FIRST CHANGE TO MAKE: a small, safe change the new hire can ship to learn the deploy process.
5. COMMON GOTCHAS: based on the code I pasted, the 3 most surprising or non-obvious behaviors.
6. WHO TO ASK ABOUT WHAT: 3-4 topics and the role of the person to ask (not a name).

Do not invent details about systems you have not seen. If something is unclear, ask me before assuming.

When to use: Two weeks before the new hire joins. · Best model: Claude Code (reads the actual repo). Claude Sonnet works for small services.

Connectors are now standard

Claude, ChatGPT, and Grok all support connectors that let your AI read live data from your work tools (Gmail, Notion, GitHub, Asana, HubSpot, Stripe, and many more) instead of relying on you to paste context. For engineers this means the AI can read your GitHub repo directly, your Sentry issue history, your Datadog logs, your Linear or Jira tickets, your Notion engineering wiki, or your Slack threads for the incident context.

For software engineers, the connectors worth pairing with these prompts:

Get Smarter About AI Every Morning

Free daily newsletter. Built for people who want to use AI well, not chase every model.

Free forever. Unsubscribe anytime.

Two ways to go further