Context Is the Whole Game

The difference between a useless answer and a good one is usually not the model. It is that the first request described the problem and the second one showed it.

A model working on your code knows only what is in front of it. It cannot open the file next door, check your package version, or know that your team decided two years ago never to throw inside that layer.

The four things worth including

1. The actual code — the function, plus the types it depends on. Not a description of the code
2. The real error, complete, including the stack trace. Truncating it removes exactly the line that identifies the cause
3. One example of your conventions — a similar existing file. This does more for output quality than any style instruction you can write in prose
4. The constraint that is not visible in the code: the runtime, the version, the thing you are not allowed to change

More context is not automatically better

Pasting your whole repository does not help. Attention is finite, and a critical detail buried inside 4,000 lines of unrelated code gets treated as background noise.

The useful skill is selection: the smallest set of files that makes the problem well-posed. If you cannot decide what is relevant, that is a signal you do not yet understand the bug — and time spent narrowing it down would have been worth spending anyway.

Project instruction files

Most AI coding tools read a project file — a rules file, a context file, an agent file — automatically on every request. This is the highest-leverage thing you can set up, because you write it once and it applies to every session afterwards.

Keep it short and specific. Long instruction files get skimmed the same way long prompts do.

Stack: Next.js 15 App Router, React 19, TypeScript strict, Tailwind v4.
Package manager: pnpm. Never suggest npm or yarn commands.

Conventions:
- Server Components by default; add "use client" only for interactivity
- Data access goes through src/lib/data.ts — never query the DB from a component
- Errors: throw AppError from src/lib/errors.ts, never bare strings

Before finishing: run `pnpm typecheck` and `pnpm lint`.
Do not add dependencies without asking.

Iterating instead of restarting

When the first answer is close but wrong, say what is wrong and what to keep. 'The validation is right; the error handling should use AppError like the file I pasted' produces a better second attempt than re-describing the whole task.

But when the answer is wrong at the root — wrong approach, wrong assumption — start a clean conversation. Long threads accumulate wrong turns, and the model keeps referring back to them.