Prompt style guide for teams that keep prompts in a codebase

Once more than one person edits prompts, you need shared conventions for the same reasons you need them for code: so reviews are fast, changes are safe, and nobody has to guess why a strange sentence is there. This guide is short enough that people will actually read it.

**What it covers**

1. **File layout**: one prompt per file under `prompts/`, named for the job, with front matter for `name`, `description`, `variables` and `owner`. Model IDs and sampling settings stay in config, not prompt text. 2. **Structure**: role and context, tagged inputs, one task, testable rules, exact output format, optional examples. Long documents go before the instructions that use them. 3. **Wording rules**: say what to do rather than only what to avoid; give the reason for unusual rules; specify length concretely; define judgment words like "urgent"; plan for empty and off-topic input; no all-caps threats; no filler; mark untrusted text as data. 4. **What does not belong**: secrets, real personal data, instructions for other features, unexplained model-specific hacks. 5. **Changing prompts**: PR with eval results, one change at a time, add the failing input to the eval set with the fix, re-run evals before rewording after a model switch. 6. **Reviewer checklist**: seven checkboxes to paste into PR templates.

**Example rule, with the reason given**

> "Keep it under 60 words because it is shown in a mobile notification" lets the model handle edge cases you did not list, where "Be brief" does not.

**What it will not do**

It is not a tutorial on prompting techniques, and it does not depend on any one model vendor. It pairs well with a prompt linter (front matter and variable checks) and a regression eval set, but works on its own as a team agreement.

Edit freely: replace the front matter keys with whatever your loader uses, and remove sections that do not apply.