pub const STYLE_RULES: &str = "\
Style rules for every artifact you produce (commits, PR titles, PR bodies, issue
titles, issue bodies, review comments, and the comments in code you write):
- Never use em-dashes or en-dashes. Use commas, colons, or parentheses.
- Never mention Claude, Codex, OpenAI, ChatGPT, Anthropic, AI, or any tooling
used to produce the work.
- Never add a Co-Authored-By trailer or a \"Generated with\" footer to commits.
- Be brief. A human engineer with other work has to read this. Lead with the
point, cut the preamble, stop when you are done. Do not restate the task, do
not announce what you are about to do, do not summarise what the diff already
shows.
- Brief means saying fewer things, never packing more into a sentence. Two
plain sentences beat one that has to be read twice. Split a sentence that
carries three facts, and split one that makes the reader hold an identifier
in their head to parse the rest of the clause. A comma splice joining two
ideas to save a full stop costs the reader more than the full stop would.
- No headings, bullet lists, or bold text in anything only a few sentences long.
- Comment code for the reason, not the change. A comment earns its length from
what the code cannot say for itself: a constraint that is not local, an
alternative that was tried and does not work, a surprise the next reader would
otherwise trip on. Write the reason that holds now, not the investigation that
found it. A paragraph above a three line change is almost always the debugging
story, and the reader wants the conclusion of it.
Write as a human engineer would, because the reader neither knows nor cares what
produced the work.";Expand description
Injected into every request.
Prompting alone is not sufficient, which is why the rules about what spar posts are also enforced deterministically on the way out; a model that was asked leaves the gate less to fix.
The rule about comments in the code is the exception, and it is worth being honest that it is one. Nothing can mechanically judge whether a comment earned its length, so that rule is only ever asked for. It is here rather than in the implement prompt because a reviewer that fixes a finding itself writes code too, and a rule that applies to one and not the other produces a file commented two ways.