100 GitHub Copilot Prompts for Developers

Explain how this project is organised.

Cover: entry points, how configuration is loaded, where tests live and how they run, and what the dependencies are used for.

Do not modify anything.

Explain what [FUNCTION] in [FILE] does.

Then answer specifically: what happens when [INPUT] is empty, null, or out of range, and is that behaviour deliberate?

Trace how [VALUE] flows through this codebase, from where it enters the system to where it is finally used or stored.

List each function it passes through, and note anywhere it is validated, transformed, or logged.

I want to change [FUNCTION] in [FILE].

Find every call site, and for each one tell me whether it would still work if I changed [WHAT YOU WANT TO CHANGE].

Do not make the change yet.

Look for half-finished work: two competing approaches to the same problem, deprecated helpers still called, TODOs referencing completed work, abandoned migrations.

Report with file and line. Change nothing.

What is [PACKAGE] used for in this project?

Show me where it is imported, what functionality depends on it, and what would break if it were removed.

Summarise [FILE] at three levels:

1. One sentence: what is this file for?
2. One paragraph per major section.
3. A list of every public function with a one-line description.

[FILE] does [THING], which looks unnecessary to me.

Make the strongest case you can for why it might have been done deliberately. What could break if I removed it?

Add a [FUNCTION NAME] function to [FILE].

Follow the structure of [EXISTING FUNCTION] in the same file: same validation approach, same error handling, same logging style, same docstring format.

Implement [FUNCTION] with this contract:

Inputs: [TYPES AND MEANING] Returns: [TYPE AND MEANING] Raises: [EXCEPTION] when [CONDITION]

Do not add dependencies. Do not change any other file.

I want a function that [DOES THING].

Before writing any code, tell me how you plan to handle: [EDGE CASE 1], [EDGE CASE 2], and invalid input.

Wait for me to agree before implementing.

Here is a sample of the data we receive:

[PASTE SAMPLE]

Generate [LANGUAGE] types for it. Flag any field where you are guessing about optionality or type, rather than assuming.

Write the argument parsing for a CLI that takes:

[LIST EACH FLAG, ITS TYPE, WHETHER IT IS REQUIRED, AND ITS DEFAULT]

Use [LIBRARY]. Include --help text for each option.

Convert this [FORMAT A] into [FORMAT B]:

[PASTE INPUT]

Preserve every field. If anything cannot be represented in the target format, tell me rather than dropping it silently.

Add a feature flag [FLAG NAME] controlling [BEHAVIOUR] in [FILE].

Default it to off. Keep the existing behaviour unchanged when the flag is off, and add a test for both paths.

Also tell me what would need to happen to remove the flag later.

Extract the [CONCERN] logic from [FILE] into a new module.

Behaviour must not change: the existing tests must pass without modification. Only those files and their imports may change. Do not rename any public function.

Run the test suite before and after, and show me both results.

Find repeated logic in this module.

For each case, tell me whether the repetition is genuine — the same rule expressed twice — or coincidental, where two things happen to look alike but change for different reasons.

Recommend unifying only the first kind.

Simplify [FUNCTION] in [FILE].

The signature and observable behaviour must not change, including for error cases.

Explain step by step why your version is equivalent.

Update [FILE] to use [LANGUAGE VERSION] idioms.

Separate your changes into two lists: purely syntactic ones, and any that could change behaviour in an edge case.

Do not apply the second kind — just tell me about them.

[CLASS OR FUNCTION] is hard to test because it depends directly on [DEPENDENCY].

Introduce the smallest seam that would let a test substitute that dependency. Do not restructure anything else.

I want to [LARGE CHANGE] in this codebase.

Break it into a sequence of steps where each step is independently shippable and leaves the tests green.

Do not start. Show me the sequence first.

This error occurs when [ACTION]:

[PASTE THE FULL TRACEBACK]

Explain the root cause. Do not change any code yet.

[TEST NAME] is failing with:

[PASTE THE FAILURE OUTPUT]

Tell me whether the test is wrong or the code is wrong, and why. Do not change either yet.

[TEST OR OPERATION] fails maybe one run in ten.

Look for sources of non-determinism: shared state between tests, wall-clock time, unseeded randomness, ordering assumptions, external network calls, or async operations not awaited.

Report what you find. Do not change anything.

This worked at [COMMIT OR VERSION] and does not now.

Here is the diff between them:

[PASTE DIFF OR NAME THE RANGE]

Which change most likely caused [SYMPTOM], and why?

Here is profiler output for [OPERATION]:

[PASTE OUTPUT]

What does this actually show is slow? Distinguish what the data supports from what you are inferring.

Users report [SYMPTOM] under [CONDITIONS].

Write a failing test that reproduces it. Do not fix anything — I want to see the test fail first.

I believe [ASSUMPTION] about this code.

Check whether that is actually true by reading the relevant files, and tell me plainly if I am wrong.

Add tests for [FUNCTION] covering: a valid input, an empty value, a boundary value, an invalid type, and the failure mode most likely in production.

Assert the specific return value or exception type for each.

Take the tests you just wrote for [FUNCTION].

For each one, tell me what change to the implementation would make it fail. If a test would still pass with the logic inverted, say so — that test is not testing anything.

Compare [MODULE] with its tests.

List behaviours the code implements that no test exercises. Prioritise by what would be most damaging if it broke.

[TEST] depends on [TIME / RANDOMNESS / EXTERNAL STATE].

Make it deterministic without weakening what it verifies. Explain what you changed and why the test still catches the original bug.

Write a test that captures [BUG] as a known failure — marked skipped or expected-to-fail, with a comment explaining the behaviour and why it is not fixed yet.

Review the tests in this project for quality rather than coverage.

Point out tests that assert implementation details rather than behaviour, tests that would pass regardless of whether the code is correct, and tests that duplicate each other.

Create test fixtures for [ENTITY].

Include awkward but legal values: empty strings, unicode, very long fields, boundary numbers, and nulls where the schema permits them. Do not use real customer data.

Write a docstring for [FUNCTION] describing its parameters, return value, and the exceptions it can raise.

Document what the code actually does. If the behaviour differs from what the function name implies, say so rather than documenting the intent.

Write a README answering: what it does, how to run it locally, how to run the tests, how configuration works, and what a newcomer is most likely to get stuck on.

Base it on what the code does, not on what sounds good.

Compare the documentation in this repository with the code.

List every place the documentation describes behaviour that no longer matches, with file and line for both sides.

Write documentation for [MODULE] aimed at [AUDIENCE — e.g. a backend developer who has never used this framework].

Assume they know [WHAT THEY KNOW] and not [WHAT THEY DO NOT].

Write an architecture decision record for [DECISION].

Cover: the context, the options considered, what was chosen, and what the trade-off was. If you cannot determine the rationale from the code, say so rather than inventing one.

Design a [METHOD] [PATH] endpoint that [DOES THING].

Follow the conventions of [EXISTING ENDPOINT]: same error shape, same status codes, same auth handling.

Show me the design before writing code.

Compare the API surface before and after this change.

List anything that would break an existing client: removed fields, newly required parameters, changed status codes, changed error shapes, or altered defaults.

Generate a [LANGUAGE] client for this API:

[PASTE SPEC OR ENDPOINT LIST]

Handle non-2xx responses explicitly. Tell me how you plan to handle timeouts and rate limiting before writing the code.

For [ENDPOINT], trace every piece of user-supplied input from the request to where it is used.

For each, tell me what validation exists between the two, and what happens if it is missing, malformed, or hostile.

List every way [ENDPOINT] can fail, and for each one give the status code and response body it should return.

Then tell me which of those it currently gets wrong.

Review this migration:

[PASTE MIGRATION]

Tell me: what locks it takes and for how long on a table with a million rows, whether it is safe to run while the old code is still deployed, and whether the down path actually works.

Here is the query and its execution plan:

[PASTE BOTH]

Explain what is slow and why. Distinguish what the plan shows from what you are inferring about the data distribution.

Look for N+1 query patterns in this codebase: places where a loop issues one query per iteration instead of a single batched query.

Report each with file and line, and estimate how many queries a typical request would issue.

This query runs frequently:

[PASTE QUERY]

What index would help? Explain what it would cost on writes and in storage, and whether an existing index already covers it.

Look at [OPERATION] in [FILE].

If it fails partway through — after step two but before step four — what state is the data left in? Is that acceptable, and is it covered by a transaction?

Write a commit message for the staged changes.

The subject line should say what changed. The body should say why, and what alternative was rejected if there was one.

Do not just restate the diff.

Summarise the changes on this branch against the base branch.

Group them by intent rather than by file, and flag anything that looks unrelated to the branch’s apparent purpose.

Explain this merge conflict: what each side was trying to achieve, and what the correct combined behaviour would be.

Do not resolve it yet.

I did [WHAT YOU DID] and now [WHAT IS WRONG].

Explain what state the repository is in and what my options are. Do not run anything yet — tell me what each option would do first.

Write a pull request description for this branch.

Cover: what problem it solves, the approach taken, anything a reviewer should look at particularly carefully, and how it was tested.

Be honest about anything incomplete.

This branch is too large to review well.

Propose a split into smaller pull requests, where each one is independently reviewable and leaves the tests passing. Tell me which must land in order and which are independent.

Read this branch as if you were reviewing it and did not write it.

What three questions would you ask? Answer them in a form I can put in the pull request description.

Here is a pull request description:

[PASTE DESCRIPTION]

Compare it with the actual diff. Does the change do what the description says, and does it do anything the description does not mention?

Review the changes on this branch for correctness only.

Look for: off-by-one errors, inverted conditions, unhandled error paths, and behaviour that changes for input the tests do not cover.

Ignore style, naming and test coverage.

Review this diff, then tell me which parts you found hardest to reason about and why.

I want to know where a human reviewer is most likely to skim.

Compare this diff against its stated purpose.

List anything changed that was not required: unrelated refactors, reformatting, renamed variables, or files touched incidentally.

Review this code for error handling.

Look for: exceptions caught and discarded, errors logged but not propagated, bare catch-all handlers, and failure paths that leave state inconsistent.

Here is my fix for [PROBLEM]:

[PASTE DIFF]

Argue against it. What could go wrong, what did I miss, and is there a simpler approach?

Find every place user input reaches a database query, shell command, file path, deserialiser, or outbound HTTP request.

For each, say what validation sits between them and what an attacker could do if it is insufficient.

Search for hard-coded credentials, API keys, tokens, connection strings or private keys — including test fixtures, example config, comments and documentation.

Report location and kind. Do not print the values.

For every route in [FILE], tell me what authentication it requires and what authorisation check it performs.

Flag any that appear to have neither, and any where the check happens after something with side effects.

Review this project’s dependencies.

Flag any that appear unmaintained, any that duplicate functionality available in the standard library, and any that seem far larger than what we use them for.

Review this configuration for defaults more permissive than needed: open network access, disabled verification, debug mode, wide permissions, missing encryption, absent retention.

Suppose [COMPONENT] were fully compromised.

What could an attacker reach from there — which credentials, which data, which other systems? What would limit the damage?

Add type hints to [FILE].

Do not use Any or add # type: ignore. If a type cannot be expressed without restructuring, tell me what the restructuring would be rather than weakening the annotation.

Review the async code.

Find: blocking calls inside coroutines, awaitables never awaited, and places that should use async with or async for.

Explain the runtime consequence, not just the pattern.

Before adding [PACKAGE], tell me: what it does that the standard library cannot, how many transitive dependencies it brings, and roughly how much code it would replace.

Then wait for me to decide.

I get [ERROR] when running [COMMAND].

The project uses a virtual environment at .venv and should be run as .venv/bin/python -m [TOOL].

Explain what is actually wrong before suggesting a fix.

Improve the types in [FILE].

Remove any and unnecessary type assertions. Do not replace one any with a union that is equally permissive. If a type genuinely cannot be narrowed, explain why.

Find every promise in this codebase that is created but not awaited or explicitly handled.

For each, tell me what happens if it rejects.

Review [COMPONENT] for unnecessary re-renders.

Explain what triggers each render before suggesting any memoisation, and tell me how I would measure whether a change helped.

Look at what this project imports and identify what is likely contributing most to bundle size.

Flag anything imported in full where a narrower import would work, and anything that could be loaded lazily.

Find every place this code acquires a resource — a connection, a stream, a file handle, a lock — and check it is released on every path, including exceptions and early returns.

For each public method in [CLASS], tell me which parameters can legally be null, whether the method handles null, and whether the return value can be null.

Base this on what the code does, not on what the names suggest.

Look at [CLASS] and tell me what assumptions it makes about being accessed from a single thread.

If it is accessed concurrently, what could go wrong and where?

Write a POSIX shell script that [DOES THING].

Quote every expansion. Guard every cd. Handle failure at each step.

Then run sh -n and shellcheck on it and fix what they report. Show me the actual output of both.

Explain what [SCRIPT] does, step by step.

Do not run it. Identify anything that deletes or overwrites, anything needing sudo, anything reaching the network, and any assumption about the environment that is not checked.

Review [SCRIPT] for what happens if each variable is unset or empty.

Pay particular attention to any variable used in a path passed to rm, mv, or a redirect.

Review this Dockerfile.

Cover: whether layers are ordered for cache efficiency, whether the final image runs as a non-root user, whether build tools leak into the runtime image, and what the image contains that it does not need.

Explain what [DOCKERFILE] produces: the base image, what gets installed, what runs at startup, what ports and volumes are exposed, and what the final image size is likely dominated by.

This container exits immediately with:

[PASTE LOGS AND EXIT CODE]

Explain the cause. Do not suggest changes until you have said what is actually happening.

Review this manifest:

[PASTE MANIFEST]

Check: resource requests and limits, liveness and readiness probes, security context, image tag specificity, and what happens during a rolling update.

Do not apply anything.

The [DEPLOYMENT] deployment is crash-looping.

Investigate using read-only commands only — get, describe, logs, events. Do not delete, restart, scale or patch anything.

Tell me what the evidence indicates and what you would change.

If I apply this change to [DEPLOYMENT], what happens to the running pods? Will there be downtime, and does the rollout strategy handle it?

Here is the plan output:

[PASTE PLAN]

List every resource that will be destroyed or replaced, what causes each replacement, and what the operational impact would be.

Do not tell me whether to apply it.

Review the infrastructure code for security concerns: public access, unencrypted storage, broad IAM, missing deletion protection, absent retention or backup.

Run only formatting and validation. Do not apply anything.

For each resource defined here, tell me what lifecycle settings are absent: retention, versioning, backup, deletion protection, or monitoring.

For each omission, say what the consequence would be.

Review this workflow.

Check: the trigger, the permissions block, whether untrusted code is checked out in a job holding secrets, whether a secret could reach a log, and whether actions are pinned.

This works locally and fails in CI with:

[PASTE THE FAILURE]

What differs between the two environments that could explain it? Consider: tool versions, working directory, checkout depth, environment variables, and available services.

Look at this workflow and tell me where the time is likely going.

Before suggesting changes, tell me what I should measure to confirm it, and what each proposed change would cost in complexity.

Diagnose why [SERVICE] is not [EXPECTED BEHAVIOUR].

Read-only commands only. Explain what each shows before running.

Do not restart services, edit config, change firewall rules, install packages, or use sudo. If a fix needs one, stop and tell me.

Here is a filtered excerpt of the logs — errors only, from the last hour:

[PASTE LOGS]

What do these indicate? Note that this is filtered, so tell me what else you would want to see.

I am considering [APPROACH] for [PROBLEM].

Constraints: [SCALE, TEAM SIZE, EXISTING STACK, DEADLINE]

Give me the strongest argument against it, and one alternative that would be better under different constraints.

Map the dependencies between the modules in this project.

Which module would be hardest to change without touching everything else, and why? Which changes would ripple furthest?

For this session, work only within [DIRECTORY].

Before making any change, describe what you plan to do and wait for my agreement.

Run [TEST COMMAND] after each change and show me the actual output.

If a task appears to require anything outside that directory, or a new dependency, stop and tell me rather than proceeding.