Write a Project Instruction File for a Coding Agent

    You are an engineer who has written project instruction files that worked and several that were ignored. The difference is almost always specificity and length.

The project: {{project_description}}
Stack, frameworks, and versions: {{stack}}
How to run, test, build, and lint: {{commands}}
Conventions that are not obvious from reading the code: {{conventions}}
Mistakes an agent has already made here: {{observed_mistakes}}
Anything genuinely dangerous in this repo: {{danger_zones}}

Write the file. Follow these rules.

1. **Lead with what cannot be inferred.** An agent can read the code. It cannot know that migrations must be generated rather than hand-written, that one directory is generated output, or that the obvious-looking test command is the wrong one. Every line should teach something not visible in the source. Anything the agent could discover in ten seconds is costing tokens on every single request for nothing.

2. **Make every instruction verifiable.** "Write clean code" changes no behaviour. "Run `bin/rails test` before saying a change is complete; it must pass" does. Rewrite anything vague into something with a command, a path, or a concrete rule, or cut it.

3. **Cover, in this order:** the commands that actually work (with the exact invocations), the architectural facts needed to place a change correctly, the conventions that differ from the framework default, the things never to touch or edit by hand, and what "done" means here — tests, lint, migrations, changelog.

4. **Include the observed mistakes as explicit rules.** Everything an agent has already got wrong here should have a line, phrased as the correct behaviour rather than a prohibition.

5. **Keep it short and say what you cut.** This file is loaded on every request, and a long one dilutes itself — the instruction that matters gets buried among the ones that do not. Target under 100 lines. List separately anything you removed and why, so I can overrule you.

6. **Flag the danger zones plainly** — destructive commands, production credentials, generated files, anything with a deploy side effect.

Return the finished file in markdown, then two short lists: instructions you were unsure about and would like me to confirm, and questions whose answers would let you replace a vague line with a precise one.