Five copy-paste prompts written for actual day-to-day work. Each names the recommended tool and the expected output shape.
Refactor suggestion with rationale
Recommended tool · Cursor · Intermediate
You are assisting a software developer. Look at the code below and propose a refactor. Output: what the code does today (1 sentence), the smell or limitation, the proposed refactor (with the new code), what tests would need to change, and any risks. Don't refactor for taste — only when there's a clear correctness, performance, or maintainability win. Code:
[paste code here]
Expected output shape
A refactor proposal with new code, test changes, and risks.
Plain-language summary of a stack trace or error
Recommended tool · Claude · Beginner
As a software developer, summarize the error below for someone non-technical: what failed, the most-likely root cause (with confidence), what would fix it, and how to know we fixed it. End with what I should ask the engineer if I want to dig deeper. Keep under 200 words. Don't paste the trace back at me. Trace:
[paste here]
Expected output shape
A plain-language explanation of the error and proposed fix.
Generate API docs from code
Recommended tool · GitHub Copilot · Intermediate
Generate API documentation for the code below as a software developer would write it. For each endpoint or public method: purpose, parameters with types and constraints, return value with example, error cases, and a curl/code example. Match the style of [existing docs / OpenAPI / Markdown]. Flag anything where the code's behavior is ambiguous and I should confirm. Code:
[paste here]
Expected output shape
API docs ready to merge into the docs site, with ambiguities flagged.
Incident summary for non-technical stakeholders
Recommended tool · Claude · Intermediate
Draft an incident summary a software developer would send to non-technical stakeholders. Cover: what happened in one sentence, who was affected, when (timeline), what we did to mitigate, what we're doing to prevent recurrence, and what stakeholders should communicate to their teams. Tone: factual, no blame, no defensive hedging. Under 300 words. Source notes:
[paste here]
Expected output shape
A clear, blameless incident summary ready to send.
Code-review checklist for a PR
Any general LLM · Intermediate
Create a code-review checklist a software developer would run on a PR for [feature type — auth, payments, data migration, etc.]. Cover: correctness checks specific to this domain, error and edge cases that often slip, security and privacy checks, test coverage gaps, and performance concerns. Mark each item with [must / should / nice]. Plain numbered list.
Expected output shape
A domain-specific code-review checklist ready to use as a PR template.