Prompt library for AI-assisted coding

Most weak results I see from coding agents come from weak prompts, not weak models. A prompt that works tends to have the same five parts.

GoalWhat should be true when the work is done, in one or two sentences.
↓→
ContextThe files, errors or tickets that matter. Point to them; don't make the agent guess.
↓→
ConstraintsWhat must not change: APIs, dependencies, style rules, off-limits files.
↓→
Acceptance criteriaTests that pass, behaviour you can observe, commands that run clean.
↓→
Plan firstFor anything bigger than a one-line fix, review a plan before any code is written.

The five parts of a prompt that works. The plan is the cheapest place to catch a wrong assumption.

Anatomy of a strong prompt

One small prompt, five jobs. Each line tells the agent something it would otherwise have to guess.

Warm-up: weak or strong?

🎮 Weak prompt or strong prompt?

1 / 8 · Score: 0

Sort each prompt. Strong ones give the agent a goal, context, limits and a finish line.

The library

Replace every [PLACEHOLDER], delete lines that don’t apply, and add what your codebase needs. No file access in your tool? Paste the code where the prompt points to it.

🧭 40 coding prompts

40 shown · 0 / 40 done

Guided tour of a repository

#1Understanding a codebase

Use it on your first day in an unfamiliar repo.

▸ Details

Starter prompt

I'm new to this repository. Give me a guided tour before I change anything.

1. Summarize what the project does and who uses it, based on the code and docs you can see.
2. List the main directories and what each one is responsible for.
3. Identify the entry points (where execution starts for the app, CLI, jobs or tests).
4. Name the key dependencies and what they are used for.
5. Point out anything unusual: custom build steps, code generation, non-standard conventions.

Only describe what you can verify in the code. Mark anything you are inferring as an assumption.
Do not modify any files.

Trace a request end to end

#2Understanding a codebase

Use it when you need to understand how one feature actually flows through the system.

▸ Details

Starter prompt

Trace what happens when [USER ACTION OR REQUEST, e.g. "a user submits the checkout form"].

Start at [ENTRY POINT, e.g. the route, handler or UI component] and follow the flow through every layer until [END STATE, e.g. the data is persisted and a response is returned].

For each step, give:
- the file and function
- what it does with the data
- any side effects (database writes, network calls, events, cache updates)

Finish with a short list of places where this flow could fail and how each failure is handled today.
Do not modify any files.

Explain a confusing piece of code

#3Understanding a codebase

Use it when a function or module doesn't make sense to you.

▸ Details

Starter prompt

Explain [FILE PATH, FUNCTION OR CLASS NAME] to me.

- What problem is it solving?
- Walk through the logic step by step, in plain language.
- Why might it have been written this way? Point to evidence in the code, comments or surrounding modules.
- What are the inputs, outputs and hidden dependencies (globals, environment variables, shared state)?
- What would break if I changed [SPECIFIC PART I'M CONSIDERING CHANGING]?

If something is genuinely unclear from the code alone, say so instead of guessing.

Map the impact of a change

#4Understanding a codebase

Use it before touching code that many other parts might depend on.

▸ Details

Starter prompt

I'm planning to change [FUNCTION, TYPE, TABLE, API OR CONFIG] so that [DESCRIPTION OF CHANGE].

Find everything that depends on it:
- direct callers and imports
- indirect uses (reflection, string references, config files, serialized data, templates)
- tests that cover it
- external consumers you can see evidence of (public API, other services, scripts)

Group the results by risk: will definitely break, might break, safe.
Do not modify any files.

Plan before code

#5Planning

Use it for any task that touches more than a couple of files.

▸ Details

Starter prompt

Goal: [WHAT SHOULD BE TRUE WHEN THIS IS DONE].

Context: [TICKET, LINKS, RELEVANT FILES OR MODULES].

Constraints:
- [e.g. no new dependencies]
- [e.g. keep the public API unchanged]
- [e.g. must work with the existing database schema]

Before writing any code, produce a plan:
1. The files you expect to create or change, and why.
2. The order of the changes.
3. How you will verify each step (tests, commands, manual checks).
4. Open questions or assumptions I should confirm.

Stop after the plan and wait for my approval.

Compare implementation options

#6Planning

Use it when there's more than one reasonable way to build something.

▸ Details

Starter prompt

I need to [PROBLEM TO SOLVE] in [PART OF THE CODEBASE].

Propose two or three different approaches. For each one:
- a short description
- what it changes in the existing code
- trade-offs: complexity, performance, testability, how easy it is to undo
- what would make it the wrong choice

Then recommend one approach for our situation, given these priorities: [e.g. ship quickly, minimize risk, long-term maintainability].
Do not write implementation code yet.

Break a feature into small steps

#7Planning

Use it to turn a large feature into reviewable, shippable pieces.

▸ Details

Starter prompt

Break this feature into a sequence of small, independently reviewable changes:

[FEATURE DESCRIPTION]

Rules:
- Each step should leave the codebase working, with tests passing.
- Each step should be small enough to review in one sitting.
- Put risky or uncertain work early so we learn fast.
- Note which steps could sit behind a feature flag.

For each step, give a one-line title, what changes, and how to verify it.

Surface hidden requirements

#8Planning

Use it when a ticket feels too simple to be true.

▸ Details

Starter prompt

Here is the task I've been given:

[TICKET OR REQUIREMENT TEXT]

Before we plan anything, act as a skeptical senior engineer. Based on this codebase, list:
- questions I should ask the requester
- edge cases the ticket doesn't mention
- existing behaviour this could conflict with
- non-functional concerns (permissions, performance, logging, localization, accessibility, data migration)

Keep it to the items that actually apply here, not a generic checklist.

Implement from an approved plan

#9Implementing

Use it right after you've reviewed and approved a plan.

▸ Details

Starter prompt

The plan above is approved. Implement step [N]: [STEP TITLE].

- Follow the existing patterns in [SIMILAR FILE OR MODULE].
- Only change the files the plan lists. If you need to touch anything else, stop and tell me why first.
- Add or update tests for the new behaviour.
- Run [TEST COMMAND] and [LINT/TYPECHECK COMMAND] and fix anything that fails.

When you're done, summarize what changed and anything that differs from the plan.

Build a feature by matching an existing one

#10Implementing

Use it when the codebase already has something very similar to what you need.

▸ Details

Starter prompt

Build [NEW FEATURE] by following the same structure as [EXISTING FEATURE, with file paths].

Match its:
- file layout and naming
- error handling
- validation approach
- test style

Differences from the existing feature:
- [DIFFERENCE 1]
- [DIFFERENCE 2]

Show me the list of files you plan to create or change before writing them.

Add an API endpoint

#11Implementing

Use it for a new route, handler or RPC method.

▸ Details

Starter prompt

Add a [HTTP METHOD] endpoint at [PATH] that [WHAT IT DOES].

Request: [FIELDS, TYPES, WHICH ARE REQUIRED]
Response: [SHAPE ON SUCCESS]
Errors: [EXPECTED ERROR CASES AND STATUS CODES]
Auth: [WHO IS ALLOWED TO CALL IT]

Follow the conventions of [EXISTING ENDPOINT FILE] for routing, validation, error format and logging.
Add tests covering success, validation failure, unauthorized access and [OTHER CASE].
Do not change existing endpoints.

Build a UI component

#12Implementing

Use it for a new front-end component that has to fit an existing design system.

▸ Details

Starter prompt

Create a [COMPONENT NAME] component in [DIRECTORY].

It should:
- [BEHAVIOUR 1]
- [BEHAVIOUR 2]
- handle loading, empty and error states

Constraints:
- Use the existing components and styles from [DESIGN SYSTEM OR FOLDER]. Do not add new styling libraries.
- It must be keyboard accessible and have proper labels for screen readers.
- Follow the prop and file conventions of [SIMILAR EXISTING COMPONENT].

Add tests for the main interactions, using the same testing approach as the rest of the project.

Tests for existing code

#13Tests

Use it to add coverage to code that has none.

▸ Details

Starter prompt

Write tests for [FILE OR FUNCTION].

First, list the behaviours you think should be tested: normal cases, edge cases and error cases. Wait for me to confirm the list.

Then write the tests:
- Use [TEST FRAMEWORK] and follow the style in [EXISTING TEST FILE].
- Test behaviour through the public interface, not implementation details.
- Mock only external boundaries (network, filesystem, time, third-party services).
- Do not change the code under test. If something is hard to test, tell me why instead.

Test-first for a new behaviour

#14Tests

Use it when you want the agent to work red, then green.

▸ Details

Starter prompt

I want to add this behaviour: [DESCRIPTION].

Work test-first:
1. Write a failing test that describes the behaviour. Run it and show me that it fails for the right reason.
2. Write the minimum code to make it pass.
3. Run the full test suite for [MODULE] to confirm nothing else broke.
4. Suggest any refactoring, but don't apply it without asking.

Repeat for each of these cases: [CASE 1], [CASE 2], [CASE 3].

Find gaps in an existing test suite

#15Tests

Use it when tests exist but you don't trust them.

▸ Details

Starter prompt

Review the tests for [MODULE] in [TEST FILE(S)] against the code in [SOURCE FILE(S)].

Tell me:
- which behaviours and branches have no test
- tests that would still pass if the code were broken (weak assertions, over-mocking)
- tests that are brittle because they depend on implementation details
- missing edge cases: empty inputs, boundaries, invalid data, concurrency, time zones

Rank the gaps by risk and propose the five tests I should add first. Do not write them yet.

Stabilize a flaky test

#16Tests

Use it when a test passes and fails without any code change.

▸ Details

Starter prompt

This test is flaky: [TEST NAME AND FILE].

Symptoms: [HOW IT FAILS, HOW OFTEN, WHERE (locally, CI, both)].
Failure output: [PASTE ERROR]

Investigate likely causes, such as timing and async waits, shared state between tests, test order, real clocks or random values, network calls, and environment differences.

Explain the most likely root cause with evidence from the code, then propose a fix that makes the test deterministic. Do not add retries or longer timeouts as the fix unless you can explain why that's actually correct.

Diagnose from an error

#17Debugging

Use it when you have a stack trace or error message and not much else.

▸ Details

Starter prompt

I'm getting this error:

[PASTE FULL ERROR AND STACK TRACE]

It happens when [STEPS TO REPRODUCE]. Expected: [EXPECTED BEHAVIOUR].
Environment: [e.g. local dev / staging / production, versions if relevant].

Before proposing a fix:
1. Explain what the error means.
2. List the likely causes, ranked, with the evidence for each in the code.
3. Tell me what to check or log to confirm which cause it is.

Don't change any code until we've confirmed the root cause.

Reproduce before fixing

#18Debugging

Use it for bug reports that are vague or hard to trigger.

▸ Details

Starter prompt

Bug report: [PASTE REPORT]

Your first job is to reproduce it, not fix it.
- Write the smallest possible failing test or script that shows the bug.
- If you can't reproduce it, tell me what information is missing and what you tried.

Once we have a reliable reproduction, propose a fix, apply it, and show that the reproduction now passes along with the existing tests.

Hypothesis-driven debugging

#19Debugging

Use it when you're stuck and the obvious fixes haven't worked.

▸ Details

Starter prompt

I'm stuck on this bug: [DESCRIPTION].

What I've already tried:
- [ATTEMPT 1 AND RESULT]
- [ATTEMPT 2 AND RESULT]

Work through it systematically:
1. List at least three hypotheses that fit all the evidence, including what I've already ruled out.
2. For each, describe a quick experiment that would confirm or eliminate it.
3. Tell me which experiment to run first and why.

After I share results, update the hypotheses. Don't jump to a fix until one hypothesis is confirmed.

Find the change that caused a regression

#20Debugging

Use it when something used to work and now doesn't.

▸ Details

Starter prompt

[FEATURE OR BEHAVIOUR] worked on [KNOWN GOOD VERSION, COMMIT OR DATE] and is broken on [CURRENT VERSION].

Here are the changes between the two: [PASTE GIT LOG, DIFF SUMMARY OR LIST OF PULL REQUESTS]

1. Identify which changes could plausibly affect this behaviour, and explain why.
2. Rank them by likelihood.
3. If the list is long, give me the exact commands to bisect it.

Once we find the cause, propose the smallest fix that restores the old behaviour without reverting unrelated work.

Behaviour-preserving refactor

#21Refactoring

Use it to clean up code without changing what it does.

▸ Details

Starter prompt

Refactor [FILE OR FUNCTION] to [GOAL, e.g. "reduce nesting and split it into smaller functions"].

Rules:
- Behaviour must stay exactly the same. No new features, no bug fixes mixed in. List any bugs you notice separately.
- Keep the public interface unchanged: [FUNCTION SIGNATURES, EXPORTS, API].
- Make sure tests cover the current behaviour first. If they don't, add characterization tests before refactoring.
- Run [TEST COMMAND] after each step.

Show me the plan first, then work in small steps.

Split a large file or class

#22Refactoring

Use it when a single file has grown into several responsibilities.

▸ Details

Starter prompt

[FILE PATH] has grown to [SIZE] and mixes several responsibilities.

1. List the distinct responsibilities you can see and which functions belong to each.
2. Propose a new structure: which modules to create, what goes where, and how they depend on each other. Avoid circular dependencies.
3. Plan the move in steps that keep the code working after each one.

Keep existing imports working (re-export if needed) unless I approve changing them. Wait for my approval before moving any code.

Remove duplication

#23Refactoring

Use it when the same logic appears in several places.

▸ Details

Starter prompt

The logic for [WHAT IS DUPLICATED] appears in several places, including [FILE 1], [FILE 2], [FILE 3].

1. Find every copy, including slightly different variants.
2. Compare them and list the real differences. Some may be intentional.
3. Propose a single shared implementation that handles the legitimate differences without piling on flags.
4. Show how each call site would change.

Do not merge copies whose differences you can't explain. Flag them for me instead.

Improve names and readability

#24Refactoring

Use it for a low-risk pass on code that's hard to read.

▸ Details

Starter prompt

Improve the readability of [FILE OR FUNCTION] without changing behaviour.

Focus on:
- clearer names for variables, functions and types
- replacing magic numbers and strings with named constants
- simplifying conditionals
- removing dead code and stale comments
- adding a short comment only where the "why" isn't obvious

Keep public names unchanged unless I approve. Show the changes as a diff with a one-line reason for each non-trivial change.

Review a diff before I open a pull request

#25Code review

Use it as a first review pass on your own work.

▸ Details

Starter prompt

Review this change before I open a pull request.

Purpose of the change: [WHAT IT'S SUPPOSED TO DO]
Diff: [PASTE DIFF, OR "the uncommitted changes in this repo", OR "this branch compared to main"]

Check for:
- bugs and logic errors
- edge cases that aren't handled
- missing or weak tests
- inconsistencies with the patterns used elsewhere in the codebase
- anything that doesn't match the stated purpose

Group findings as: must fix, should fix, nitpick. For each, point to the exact location and explain why. Don't rewrite the code; just review it.

Review someone else's pull request

#26Code review

Use it to prepare for reviewing a teammate's work.

▸ Details

Starter prompt

Help me review this pull request.

Description from the author: [PASTE PR DESCRIPTION]
Diff: [PASTE DIFF OR POINT TO BRANCH]

1. Summarize what the change does in plain language.
2. Check whether the implementation matches the description.
3. List the questions I should ask the author.
4. Flag risks: correctness, security, performance, backward compatibility, missing tests.

Keep the tone of any suggested comments constructive and specific. I'll decide what to post.

Check a change against team standards

#27Code review

Use it when your team has written conventions and you want them applied consistently.

▸ Details

Starter prompt

Here are our team's coding standards:

[PASTE STANDARDS OR POINT TO THE FILE]

Review [DIFF OR FILES] against them. For each violation, give the rule, the location and a suggested fix.

Only report real violations of the written standards. Don't add your own style preferences, and say so if the standards don't cover something you think matters.

Write a README for a module

#28Docs

Use it when a module has no documentation, or the documentation is out of date.

▸ Details

Starter prompt

Write a README for [MODULE OR DIRECTORY].

Include:
- what it does and when to use it
- how to set it up and run it locally
- the main public functions or endpoints, with a short example each
- configuration options and environment variables
- known limitations

Base everything on the actual code. If something is unclear, add a TODO for me rather than guessing. Keep it concise; developers should be able to scan it in two minutes.

Document a function or API

#29Docs

Use it for inline documentation that matches the project's style.

▸ Details

Starter prompt

Add documentation comments to the public functions in [FILE].

- Follow the existing doc comment style in [EXAMPLE FILE, or the language's standard format].
- For each function: what it does, parameters, return value, errors it can raise, and a short example if the usage isn't obvious.
- Don't restate what the code already says clearly. Focus on intent, constraints and gotchas.
- Don't change any code.

Record an architecture decision

#30Docs

Use it to capture the reasoning behind a technical choice while it's still fresh.

▸ Details

Starter prompt

Write an architecture decision record (ADR) for this decision:

Decision: [WHAT WE DECIDED]
Context: [THE PROBLEM AND CONSTRAINTS]
Options we considered: [OPTION A, OPTION B, OPTION C]
Why we chose it: [REASONS]

Use these sections: Title, Status, Context, Decision, Alternatives considered, Consequences (positive and negative).
Keep it under one page. Where I haven't given you a reason, leave a clear placeholder instead of inventing one.

Find a performance bottleneck

#31Performance

Use it when something is slow and you don't yet know why.

▸ Details

Starter prompt

[OPERATION, PAGE OR ENDPOINT] is slow. It takes about [CURRENT TIME] and should take under [TARGET].

Relevant code: [FILES OR ENTRY POINT]
Profiling or timing data, if any: [PASTE]

1. Read the code path and list likely bottlenecks: repeated work, N+1 queries, blocking I/O, large allocations, missing indexes, unnecessary re-renders.
2. For each, explain how to measure whether it's actually the problem.
3. Don't optimize anything yet. Tell me what to measure first.

Optimize with a measurable target

#32Performance

Use it once you know where the time goes.

▸ Details

Starter prompt

The bottleneck is [SPECIFIC CODE AND WHAT MAKES IT SLOW], confirmed by [MEASUREMENT].

Optimize it with these constraints:
- Behaviour and output must stay identical. Existing tests must pass.
- Target: [e.g. under 200 ms for 10,000 records].
- Prefer the simplest change that reaches the target. Explain any trade-off in readability or memory.

Before and after, give me the exact command or benchmark to run so I can verify the improvement myself.

Review database queries

#33Performance

Use it when data access might be the slow part.

▸ Details

Starter prompt

Review the database queries in [FILES, REPOSITORY LAYER OR ORM MODELS] for performance problems.

Database: [ENGINE AND VERSION]
Approximate table sizes: [e.g. orders: 5M rows, users: 200k rows]
Schema and indexes: [PASTE OR POINT TO MIGRATIONS]

Look for N+1 patterns, missing or unused indexes, full table scans, over-fetching columns or rows, and queries inside loops.

For each issue, show the query, explain the problem, and propose a fix. If you suggest an index, tell me how to check it with the query plan before adding it.

Security review of a change

#34Security

Use it before merging anything that touches input handling, auth or data access.

▸ Details

Starter prompt

Do a security review of [DIFF, FILES OR FEATURE].

Check for:
- injection (SQL, command, template, path traversal)
- missing or incorrect authentication and authorization checks
- unsafe handling of user input and output encoding
- secrets or credentials in code, logs or error messages
- insecure defaults and overly broad permissions
- sensitive data exposed in responses or logs

For each finding: location, what an attacker could do, severity (high, medium, low), and a concrete fix. Only report issues you can point to in the code, and say how confident you are in each one.

Audit an authorization flow

#35Security

Use it to check who can actually do what.

▸ Details

Starter prompt

Audit authorization for [FEATURE OR RESOURCE, e.g. "editing invoices"].

Roles in the system: [LIST ROLES]
Expected rules: [WHO SHOULD BE ABLE TO DO WHAT]

1. Find every code path that reads or changes this resource (UI, API, background jobs, admin tools).
2. For each path, show where access is checked, or state that it isn't.
3. Compare the actual checks with the expected rules and list every mismatch.
4. Point out any place where the check relies on data the client controls.

Do not modify code. Give me the findings as a table.

Review dependencies and configuration

#36Security

Use it for a periodic check of what your project pulls in and how it's configured.

▸ Details

Starter prompt

Review the dependency manifest [e.g. package.json, requirements.txt, go.mod] and the configuration in [CONFIG FILES].

Flag:
- dependencies that look unused, duplicated or abandoned
- very broad version ranges
- debug settings, permissive CORS, disabled security headers or verbose error output that could reach production
- secrets committed to the repository

For anything version-specific (known vulnerabilities, end-of-life dates), don't rely on memory. Tell me which command or tool to run to check it.

Plan a dependency or framework upgrade

#37Migrations

Use it before upgrading anything with breaking changes.

▸ Details

Starter prompt

I want to upgrade [LIBRARY OR FRAMEWORK] from [CURRENT VERSION] to [TARGET VERSION].

Here are the official migration notes or changelog: [PASTE OR SUMMARIZE]

1. Find every place in this codebase affected by the breaking changes listed.
2. Estimate the size of each change (trivial, moderate, significant).
3. Propose an upgrade order that keeps the app working, including any intermediate versions.
4. List what to test manually after the upgrade.

Only rely on the migration notes I've given you for version-specific changes. If you need information I haven't provided, ask for it.

Write a safe database migration

#38Migrations

Use it for schema changes on a database that's already in production.

▸ Details

Starter prompt

I need to change the schema: [DESCRIPTION, e.g. "split the name column into first_name and last_name"].

Database: [ENGINE AND VERSION]
Migration tool: [TOOL]
Table size: [APPROXIMATE ROW COUNT]
Constraints: [e.g. no downtime, the old app version must keep working during the deploy]

Write the migration so that:
- it can run while the app is live (expand, then migrate data, then contract, if needed)
- it has a working rollback
- the data backfill runs in batches if the table is large

Explain the deploy order: which migration steps go before, during and after the code change.

Migrate a pattern across the codebase

#39Migrations

Use it for large, repetitive changes, such as moving from one API or library to another.

▸ Details

Starter prompt

Migrate all uses of [OLD PATTERN OR API] to [NEW PATTERN OR API].

Example of the change:
Before: [CODE SAMPLE]
After: [CODE SAMPLE]

1. Find every occurrence and give me the count, grouped by directory.
2. Identify the cases that don't fit the simple before/after example and explain why.
3. Migrate the simple cases first, one directory at a time, running [TEST COMMAND] after each batch.
4. Leave the unusual cases for me to review, with a note on each.

Port code to another language or framework

#40Migrations

Use it when rewriting a module rather than upgrading it.

▸ Details

Starter prompt

Port [FILE OR MODULE] from [SOURCE LANGUAGE OR FRAMEWORK] to [TARGET LANGUAGE OR FRAMEWORK].

- Preserve behaviour exactly, including error cases and edge cases.
- Write idiomatic [TARGET] code rather than a line-by-line translation.
- Follow the conventions in [EXISTING TARGET-LANGUAGE CODE IN THIS REPO].
- Port or write tests that prove the new version behaves the same as the old one.

Before writing code, list anything that doesn't translate directly (library features, concurrency model, type differences) and how you plan to handle each.