AI right in your editor: Copilot and friends for developers

I'm about to start this task in our project:
[task description, e.g. add support for partial refunds to the
order module]

Stack: [language, framework, version]. Project size: [rough order of
magnitude].
Tests: [unit yes, integration partial, coverage about 40%].
Deadline: [2 days].

Don't write any code yet. Break the task into steps and for each
one write:
1. what needs to be done, one sentence,
2. whether it's a decision (I need to make it) or mechanics (AI can
   write it and I'll review it),
3. what needs to be verified before moving on,
4. what this step could break elsewhere in the system.

At the end, list three questions I should answer before I start, and
one thing about this request you think is underspecified.

Go through this project and write me a draft rules file for the AI
assistant that will work in it. Base it on what you actually see in
the code, not on general recommendations.

Include:
- language, version, package manager, how the project is run and
  tested
- directory layout and what belongs where
- naming conventions actually followed in the code (even where they
  differ from the usual recommendations for this language)
- how the project handles errors, logging, and configuration
- what a typical test looks like and which libraries are used
- what is NOT done in this project (banned libraries, patterns we
  got rid of and don't want back)
- areas where nothing may change without consultation
  (authentication, payments, database migrations)

For each point, cite the file you derived it from.
Where you see two different styles in the project, list both and
flag it as a decision to be made — don't choose for me.

Explain this module to me. I'm an experienced developer, but I'm
seeing this project for the first time.

I don't want the code retold line by line. I want:
1. What the module is for and what problem it solves — 3 sentences.
2. Public interface: what other parts of the system call here and
   what they expect back.
3. Data flow: what comes in, how it changes step by step, what goes
   out and where.
4. State and side effects: what it remembers, what it writes to the
   database, what it sends to other services.
5. Three spots where the logic is most tangled, and why — file and
   line numbers for each.
6. Assumptions the code silently makes (what has to be true about
   the inputs for it to work) — especially ones that are never
   checked anywhere.
7. What I'd break if I changed something here.

Where you're not sure, say so instead of guessing. Don't claim
anything about code you can't see.

[attach the module or directory]

Go through this repository and describe the whole path
[a specific request takes through the system, e.g. an order, from
form submission to the confirmation email].

For each step, give me:
- the file and function where it happens,
- what happens to the data at that step,
- where a branch is decided (validation, authorization, a feature
  flag),
- where it can fail, and what happens to the in-progress state then.

At the end, tell me:
- which steps aren't covered by tests,
- where this path differs from what I'd expect based on the file
  names,
- three spots where I'd most likely break something if I touched
  this.

I want concrete file-and-line references, not a general
architecture description.

Here's the function [name] I need tests for:
[paste the function and related types]

Its intended behavior, per the business logic:
[3-6 sentences in your own words, including what it should do in
edge cases — empty input, a negative amount, a missing value]

Write tests in [framework], in the style we use here:
[attach one existing test file as a sample]

Rules:
- test the behavior described above, not what you see in the
  implementation,
- for each test, one sentence on what it verifies and why it
  matters,
- cover edge cases: boundaries, empty and missing values, error
  states — for each one, write why that particular case is
  interesting,
- don't mock the internals of the function under test, only its
  external dependencies,
- at the end, list separately: cases where the intended behavior per
  the description DIVERGES from what the implementation actually
  does.

That last list is the most important part for me — don't leave it out.

I found a bug: [description of what happens and what should happen
instead].
Reproduction: [steps or input that triggers it].
Suspected location: [file, function].

Write me one test that catches this bug — a test that MUST fail
right now and pass once it's fixed.

- name it so the name makes clear which case it's guarding,
- add a comment linking to the report and briefly what it was about,
- use only the data that's essential to the bug, no random filler,
- don't fix the code yet — I want to see the test fail first.

Once the test fails, only then propose a fix — and along with it,
explain why the bug happened and what else could have been affected
by the same root cause.

This function has grown beyond me:
[paste the code]

Context: [what it's for, how often it's called, what calls it].
Tests: [exist / don't exist]. Performance is [/isn't] critical.

Don't write the result yet. First give me:
1. What's specifically wrong with this function — a numbered list of
   problems, and for each, why it hurts in practice (readability,
   testability, risk of bugs), not a reference to a general
   principle.
2. Three different refactoring options, from smallest to most
   radical. For each: what improves, what gets worse, how many files
   it touches, and whether it changes the public interface.
3. Which one you'd pick, and why — given [the context above].

I'll choose, and only then write me the code. Behavior must not
change; where it would have to, flag that in advance.

Here's the diff I'm about to commit. Part of the code was written
with AI's help, and I want it reviewed as if someone else had
written it.

Context: [what the change does and why]. Project: [stack].

Go through the diff and return findings sorted into groups:
1. BUGS: what's wrong and will show up (incorrect behavior, an
   unhandled edge case, a behavior change compared to the original
   code).
2. SECURITY: unvalidated input, missing authorization checks,
   handling of secrets, injection risk, logging of sensitive data.
3. NONEXISTENT API: calls to functions, methods, or parameters that
   may not exist in the stated library versions — list them so I can
   verify them in the docs.
4. EXTRA: code that solves a problem I don't have — abstractions,
   parameters, and branches nobody calls.
5. MISMATCH WITH THE PROJECT: where this diverges from the
   conventions in the attached rules file.

For each finding: file, line, what to do about it. Don't fix
anything yourself.
At the end, write three questions I should be able to answer when
defending this change.

Here's the diff of my commit:
[paste the diff]

Context that isn't visible from the diff:
[why I'm doing this, the ticket number, what led up to it]

Write a commit message following [e.g. Conventional Commits]
convention, in [English / your language] per the repository's
habits:
- first line under 72 characters, imperative mood, no period,
- a blank line,
- body: WHY this change exists and what alternatives it had, not a
  retold list of changed files,
- if behavior or an interface changes, state it explicitly,
- a ticket reference at the end.

If you see two unrelated changes in the diff, don't fold them into
one message — tell me where to split it into separate commits.

Draft a pull request description from this diff and these commits:
[paste the diff and the list of commits]

Context: [ticket, the requirements, what we agreed on].

Structure:
- What's changing and why — 3 sentences, clear even for a coworker
  on another team.
- How I approached it, and what alternatives I considered and
  rejected.
- What the reviewer should look at carefully, and why that
  specifically.
- How to test it manually — concrete steps, not “run the app”.
- Risks, and what to do if this needs to be rolled back.
- What is deliberately NOT part of this change.

Write it briefly, no marketing language. Where information is
missing, write FILL IN: [what] instead of making it up.

Work in this repository.

TASK: [e.g. replace deprecated calls to library X with the new API
across the project — there are about 40 of them].

SCOPE: only the [src/, tests/] directories. Don't touch
[migrations/, infra/, deployment configuration] or dependencies in
the manifest.

PROCESS, stop after each step and wait for my approval:
1. Find every affected spot and list it in a table: file, line, type
   of usage. Sort them into straightforward cases and ones that
   require a decision.
2. For the three most complex cases, show me the proposed change and
   explain it.
3. Make the change in one file, run the tests, show me the diff.
4. Only after approval, process the rest of the straightforward
   cases, in two batches, each with its own commit.
5. Leave the cases requiring a decision unchanged and list them for
   me at the end with your recommendation.

DONE MEANS: all existing tests pass, behavior doesn't change, the
diff contains no unrelated formatting changes.

PROHIBITIONS: don't delete tests, don't modify them except for the
changed interface, don't update dependency versions, don't rewrite
code unrelated to the task, don't commit without my approval.