Software Development prompts

Plain-English error, ranked checks.

Act as a senior [language] engineer. Decode this error for me in plain terms: [paste full error and stack trace]. Tell me what it actually means, the most common causes, and the first three things I should check, in order. Then ask me for any context you'd need to narrow it down.

Root cause, not symptom.

Here's a bug: expected [behaviour], but I'm getting [behaviour]. Relevant code: [paste]. Language and version: [version]. Walk through the code's logic step by step, point out where it diverges from what I expect, and give me the smallest change that fixes the root cause, not just the symptom.

Environment causes, ranked.

This code works locally but fails in [environment]: [paste code and error]. List the environment-specific causes worth checking, config, versions, env vars, permissions, timeouts, networking, ranked by how likely they are for this stack, and how I'd confirm each.

Usual suspects for flakiness.

I have an intermittent bug that's hard to reproduce: [describe the symptom and paste relevant code]. Give me the usual suspects for flaky behaviour here, race conditions, state, timing, external dependencies, and suggest logging or a minimal test that would help me catch it in the act.

Strip it to the bug.

Help me write a minimal reproducible example for this problem: [describe and paste code]. Strip it down to the smallest self-contained snippet that still shows the bug, so I can isolate it or file a clean issue. Tell me what you removed and why it's safe to remove.

Grouped, prioritised feedback.

Act as a thorough but pragmatic code reviewer. Review this diff: [paste]. Group your feedback into bugs and correctness, security, edge cases, readability, and nitpicks, and mark each as must-fix or optional. Be specific about why, and don't invent problems to seem thorough.

Hunt injection and secrets.

Review this code specifically for security issues: [paste]. Look for injection, unsafe input handling, exposed secrets, missing authorisation checks, and unsafe dependencies. For each finding, explain the risk and the fix, and tell me if you're unsure rather than guessing.

Inputs likely to break it.

Stress-test this function for edge cases: [paste]. List the inputs and conditions most likely to break it, empty, null, huge, malformed, concurrent, boundary values, and for each say what would happen and whether it's handled. Then suggest the two or three worth guarding against.

Catch it before humans do.

Before I open a PR, review my own code as a skeptical teammate would: [paste]. Tell me what you'd push back on, what's unclear, and what I've probably missed, so I can fix it before a human sees it. Prioritise the three things most worth changing.

Behaviour preserved, cleaner code.

Refactor this code for readability without changing its behaviour: [paste]. Explain each change and why it's clearer, keep the same public interface and outputs, and flag anything where the refactor might subtly change behaviour so I can test it.

Single responsibilities, same behaviour.

This function is too long and does too much: [paste]. Break it into smaller, well-named functions with single responsibilities, keep the external behaviour identical, and show me the new structure with a one-line note on what each piece does.

Hot path, impact over effort.

Help me optimise this for performance: [paste code, and describe the bottleneck or paste a profile if I have one]. Identify the likely hot path, suggest changes ranked by expected impact versus effort, and be honest about which are premature optimisation I can skip. Don't sacrifice correctness for speed.

Abstract only where it helps.

Find and reduce duplication across these snippets: [paste]. Suggest a clean shared abstraction only where it genuinely helps, warn me if extracting it would be over-engineering, and keep the result easy to read rather than clever.

Happy path, edges, errors.

Write unit tests for this function using [test framework]: [paste]. Cover the happy path, edge cases, and error states, name each test by what it checks, and tell me which behaviours you weren't sure about so I can confirm the assertions are actually correct, not just passing.

The edges people forget.

Here's a function and its intended behaviour: [paste code and spec]. List the test cases I should have before I trust this, including the nasty edge cases people forget, and mark which are must-have versus nice-to-have. Then write the must-haves in [framework].

Scenarios that reduce risk.

Act as a QA engineer. Given this feature, [describe and paste key code], write a test plan: the scenarios to cover, the edge and failure cases, and the one or two integration points most likely to break. Keep it to what actually reduces risk, not exhaustive box-ticking.

Tests before the code.

I'm doing TDD. Here's the spec for a function I haven't written yet: [describe]. Write the failing tests first in [framework], covering the behaviour and edge cases, so I can implement against them. Don't write the implementation, just the tests.

Comment the why, not what.

Write clear docstrings or comments for this code: [paste]. Explain what each function does, its parameters and return, and any non-obvious behaviour or side effects, in the [language] convention. Comment the why, not the obvious what, and don't restate the code line by line.

Skimmable for a cold reader.

Draft a README for this project: [paste key files or describe]. Cover what it does, how to install and run it, basic usage with an example, and configuration. Keep it skimmable for a developer landing on it cold, and mark anything you had to assume so I can correct it.

Endpoints, params, examples, errors.

Generate API documentation for these endpoints: [paste routes or code]. For each, give the method, path, parameters, request and response examples, and error responses, in a clean table or the [format] style. Flag any endpoint where the behaviour isn't clear from the code.

Walked through like onboarding.

Explain this complex or unfamiliar function to me like a senior engineer walking a new teammate through it: [paste]. Cover what it does, why it's built this way, and the gotchas, then note anything that looks like a bug or a smell worth a second look.

Approaches, trade-offs, a pick.

Act as a staff engineer. I need to design [component or system]. Requirements: [list]. Constraints: [list, e.g. scale, latency, team, stack]. Propose two or three approaches, with the trade-offs of each, and recommend one with your reasoning. Call out the assumptions that would change the answer.

Honest trade-off table.

Compare [approach A] versus [approach B] for [problem], given my context: [describe]. Give me an honest trade-off table across the dimensions that matter here, performance, complexity, cost, maintainability, and tell me which you'd choose and when the other one wins instead.

Argue against it first.

Review my proposed design as a skeptical architect: [describe or paste]. Where will this struggle at scale, what failure modes am I not handling, and what's the simplest version that would still meet the requirements? Argue the case against it before you agree with it.

Only if it earns complexity.

Which design pattern, if any, fits this problem: [describe]? Suggest one or two that genuinely apply, show roughly how they'd look in [language], and warn me if reaching for a pattern here would add complexity without real benefit. Plain code beats a clever pattern I don't need.

Purpose, pieces, danger zones.

Explain this module I've inherited: [paste]. Give me the high-level purpose, how the main pieces fit together, the key data flow, and the parts I should be careful editing. Assume I know the language but not this codebase.

Entry to result, step by step.

Trace how [a request / an event / a value] flows through this code: [paste relevant files]. Walk it step by step from entry to result, name the functions it passes through, and flag where state changes or something could go wrong.

Five files to read first.

I'm onboarding to this codebase. Based on these files, [paste or describe structure], give me a mental map: the main components, the conventions the team seems to follow, and the five files I should read first to understand how it works.

Query, index, one edge case.

Write a [dialect] SQL query that [describe what you need]. Here's the relevant schema: [paste]. Explain what the query does, watch for performance on large tables, and suggest an index if it would help. Then show me one edge case that might return wrong results.

Explained, with tricky tests.

Build a regex that matches [describe precisely, with examples that should and shouldn't match]. Explain each part of the pattern in plain terms, note the flavour or flags it needs, and give me a couple of test strings to confirm it, including a tricky one.

With a destructive-action warning.

I need to [describe a git or shell task, e.g. undo a merge, rewrite the last commit, find a string across history]. Give me the exact command, explain what each part does and what it changes, and warn me clearly if it's destructive or rewrites history before I run it.

What, why, how to test.

Write a pull request description for this change: [paste the diff or describe]. Include what changed and why, how to test it, any risks or follow-ups, and anything a reviewer should focus on. Keep it concise and skimmable, not a wall of text.

Conventional commits, no filler.

Write a clear commit message for this change following conventional commits: [paste diff or describe]. A concise summary line under 72 characters, then a short body on the what and why if it's non-trivial. No filler.

User-facing, grouped, migration flags.

Draft a changelog entry for this release from these merged changes: [paste PR titles or notes]. Group them into features, fixes, and breaking changes, write each in user-facing language rather than internal jargon, and flag anything that needs a migration note.