Briefing a coding assistant: the first message

A coding assistant works from what you tell it and what it sees in the repository. A first message that names the goal, the boundary and the way to check the result saves more time than any correction later.

State the goal and the boundary

Fix the bug where the export button downloads an empty file. Change only the export code and do not refactor anything nearby. Leave out the second sentence and an assistant often improves things you never asked about, and you review a larger diff.

Point at the files

Name the files or functions that matter, and say which to leave alone. It cuts search time and guessing.

Give the failing case

The exact error message, the input that triggers it, what you expected and what happened. A reproducible case is the most useful thing you can hand over.

Say how to check it

Run the tests in tests/export and tell me the result, or add a test that fails before the fix and passes after. An assistant that can verify its own work catches its own mistakes.

Ask for a plan when the change is large

Before changing anything, list the files you would edit and why. Reading a plan takes a minute. Reviewing a wrong change takes far longer.

Keep repeating rules in a file

Anything you would say in every session, such as the test command or folders to avoid, belongs in a config file the tool reads automatically. See moving-your-rules-into-a-config-file.

Read the diff

Review what changed and not only whether it runs. senior-engineer-who-reads-before-changing is an instruction that keeps an assistant from making changes you did not request.