8 AI prompts for developers (copy-ready and tested)

All 8 prompts

• Prompt: Write a Commit Message and PR Description

  Score 89

  A prompt for a clear commit message and pull request description built from your actual diff, explaining why the change was made.

  Show prompt

  The prompt Copy

  You are a senior engineer writing a commit message and PR description for review by teammates.
  
  Objective: Write a commit message and PR description for the change below.
  
  Context: What problem this change solves: {{WHAT PROBLEM THIS SOLVES}}. Anything reviewers should pay special attention to: {{REVIEWER FOCUS — e.g. edge case, performance, breaking change}}.
  
  Constraints:
  - Commit message subject line under 50 characters, imperative mood (e.g. "Fix", not "Fixed" or "Fixes")
  - PR description must explain why the change was made, not just restate the diff
  - List what was NOT changed if that's relevant context (e.g. "does not touch the API layer")
  - Do not invent testing that wasn't described — if no testing is mentioned, say "testing not specified" instead
  
  Output format: Return the commit message (subject + body), then a separate "PR description" section with "What changed", "Why", and "Reviewer notes".
  
  Before finishing, check the subject line is under 50 characters and in imperative mood.
  
  Diff or change summary:
  {{PASTE DIFF OR CHANGE SUMMARY HERE}}
  

  View full page →

• Prompt: Explain Unfamiliar Code

  Score 74

  A prompt for a clear, layered explanation of unfamiliar code — what it does, how data flows, and what's risky — before you change it.

  Show prompt

  The prompt Copy

  You are a senior engineer helping a colleague understand code they didn't write before they modify it.
  
  Objective: Explain what the code below does, written in {{LANGUAGE}}.
  
  Context: Why I need to understand it: {{REASON — e.g. about to fix a bug, adding a feature, reviewing a PR}}.
  
  Constraints:
  - Start with a one-paragraph summary of what the code does overall, in plain language
  - Then walk through it in logical sections (not line by line), explaining what each section does and why it likely exists
  - Explicitly flag anything that looks risky, unusual, or likely to break if changed carelessly
  - Do not guess at business intent you can't infer from the code — say "unclear from the code" instead
  
  Output format: Return a "Summary" section, a "Walkthrough" section with subheadings, and a "Risks and unknowns" section.
  
  Before finishing, check that every claim about what the code does is traceable to a specific line or block, not assumed.
  
  Code:
  ```
  {{PASTE CODE HERE}}
  ```
  

  View full page →

• Prompt: Build a Refactor Plan

  Score 73

  A prompt for a staged, low-risk refactor plan that separates behaviour-preserving cleanup from riskier structural changes.

  Show prompt

  The prompt Copy

  You are a senior engineer planning a refactor before writing any code.
  
  Objective: Build a staged refactor plan for the code below, written in {{LANGUAGE}}, with the goal: {{REFACTOR GOAL — e.g. reduce duplication, improve testability, split a large function}}.
  
  Context: Current test coverage: {{TEST COVERAGE — e.g. none, partial, full}}. Constraints on the refactor: {{CONSTRAINTS — e.g. can't change the public API, must ship incrementally}}.
  
  Constraints:
  - Split the plan into stages ordered from lowest to highest risk; each stage must be independently shippable
  - For each stage, state what changes and what must NOT change (behaviour preservation)
  - If test coverage is not "full", recommend which tests to add before the riskiest stage, not after
  - Flag any stage that would require a change to the public API given the constraints
  
  Output format: Return a numbered list of stages, each with "Changes", "Must not change", and where relevant "Tests to add first".
  
  Before finishing, check that no stage depends on a later stage being completed first.
  
  Code:
  ```
  {{PASTE CODE HERE}}
  ```
  

  View full page →

• Prompt: Write Documentation for a Function or Module

  Score 78

  A prompt for clear reference documentation — parameters, return values, edge cases and a usage example — generated from the actual code.

  Show prompt

  The prompt Copy

  You are a technical writer producing reference documentation for other developers who'll use this code.
  
  Objective: Write documentation for the function or module below, written in {{LANGUAGE}}.
  
  Context: Where this documentation will be used: {{DOCUMENTATION TARGET — e.g. README, internal wiki, docstring}}.
  
  Constraints:
  - Document only behaviour visible in the code — do not invent parameters, return types or side effects not present
  - Include: purpose, parameters (with types), return value, at least one documented edge case or error condition, and one usage example
  - Flag any parameter or return path whose behaviour is ambiguous from the code as "needs confirmation"
  - Match the output format to the documentation target (Markdown for README/wiki, docstring format for inline)
  
  Output format: Return the documentation formatted for {{DOCUMENTATION TARGET}}, with a short usage example in a fenced code block.
  
  Before finishing, check every documented parameter and return value against the code, and confirm no invented behaviour was added.
  
  Code:
  ```
  {{PASTE CODE HERE}}
  ```
  

  View full page →

• Prompt: Write an SQL Query

  Score 80

  A prompt that gets a correct, readable SQL query on the first try by giving the model your schema and edge cases up front.

  Show prompt

  The prompt Copy

  You are a database engineer who writes SQL that's easy for the next person to read.
  
  Objective: Write a {{DIALECT — e.g. PostgreSQL, MySQL, SQLite}} query that {{DESCRIBE WHAT THE QUERY SHOULD RETURN}}.
  
  Context: {{TABLE SCHEMAS — paste the columns and types}}
  
  Constraints:
  - Use explicit column names, never SELECT *
  - Handle NULLs explicitly if the result could contain them
  - Add a one-line comment above any non-obvious join or subquery
  - Do not invent column or table names that weren't given
  
  Example: "customers who placed more than 3 orders in the last 90 days" is specific enough to write directly; "our best customers" is not.
  
  Output format: Return the query in a single fenced SQL code block, followed by one sentence explaining what it does in plain English.
  
  Before answering, check the query against the schema given and confirm every referenced column actually exists there.
  

  View full page →

• Prompt: Code Review Feedback

  Score 84

  Get a structured, honest code review from an AI model instead of a vague 'looks good to me' or a wall of unprioritised nitpicks.

  Show prompt

  The prompt Copy

  You are a principal engineer reviewing a pull request for the developers who'll merge and maintain it.
  
  Objective: Review the code below for correctness, security and maintainability.
  
  Context: {{Language/framework, and what this code is supposed to do}}
  
  Constraints:
  - Separate findings into Critical, Important and Minor — do not mix severities
  - For each finding, give the specific line or block, not a general comment
  - Do not suggest a rewrite unless the current approach is actually wrong
  - Only flag style issues if they violate the project's stated conventions
  
  Example: a missing null check on user input is Critical; an inconsistent variable name is Minor.
  
  Output format: Return findings as a Markdown list grouped by severity, then one sentence saying whether you'd approve, request changes, or need more context.
  
  Before answering, verify each Critical finding would actually cause a bug or vulnerability, not just a stylistic preference.
  
  Code:
  ```
  {{PASTE CODE HERE}}
  ```
  

  View full page →

• Prompt: Write Unit Tests

  Score 83

  A copy-ready prompt for getting real, meaningful unit tests out of an AI model — covering edge cases, not just the happy path.

  Show prompt

  The prompt Copy

  You are a senior software engineer writing tests for the developers who'll maintain this code after you.
  
  Objective: Write unit tests for the function below using {{TEST FRAMEWORK — e.g. Jest, pytest, JUnit}}.
  
  Context: {{Paste any existing test file's style/conventions here, or say "no existing tests"}}
  
  Constraints:
  - Cover the happy path, at least two edge cases, and one invalid-input case
  - Do not test implementation details — test observable behaviour only
  - Use descriptive test names that state the expected behaviour, not the method name
  - Do not mock anything that isn't an external dependency
  
  Example: it("returns an empty array when given zero items", ...) — a name describing behaviour, not it("test1").
  
  Output format: Return the test file in a single fenced code block, followed by a short bullet list explaining what each test group covers.
  
  Before finishing, check that every test would actually fail if the corresponding bug were introduced.
  
  Function:
  ```
  {{PASTE FUNCTION HERE}}
  ```
  

  View full page →

• Prompt: Debug Python Code

  Score 76

  A copy-ready debugging prompt that gets the model to diagnose before it fixes — with reproduction steps, root cause and a tested correction.

  Show prompt

  The prompt Copy

  You are a senior Python developer. Debug the code below.
  
  Follow this process strictly:
  1. State what the code is trying to do (one sentence)
  2. Identify the exact line(s) causing the problem and explain why
  3. Explain the root cause, not just the symptom
  4. Provide the corrected code in full
  5. List anything else in the code that will cause problems later
  
  Rules:
  - Do not rewrite working parts unnecessarily
  - Keep the original style and naming
  - If the error message or expected behaviour is missing, ask before guessing
  
  Before answering, verify your proposed fix actually resolves the stated error and does not introduce new ones.
  
  Error message (if any): {{ERROR}}
  Expected behaviour: {{WHAT SHOULD HAPPEN}}
  
  Code:
  ```python
  {{PASTE CODE HERE}}
  ```
  

  View full page →