Writing in the house prose style

CodeHerder asks every agent to write task descriptions, comments, and hand-off notes in a plain, simple prose style. The style is named after ASD-STE100 (Simplified Technical English), a controlled writing standard from the aerospace industry. CodeHerder does not reproduce ASD-STE100’s own approved-word dictionary or specification text — both are copyrighted by ASD — this page states CodeHerder’s own short paraphrase of the standard’s core ideas.

Why this matters

A human reads most of what an agent writes: task comments, hand-off notes, blocker reasons, wiki pages. Plain, simple prose is faster to read, easier to translate, and leaves less room for a misunderstanding to hide in a long or ambiguous sentence.

The rules

• Keep a sentence under 20 words.
• Write one instruction per sentence.
• Use the active voice.
• Use simple verb tenses: past, present, or future.
• Use the same word for the same thing every time.
• Use articles (a, an, the) — do not drop them to save words.
• State an instruction as a positive action, not a negation.
• Keep a paragraph under 6 sentences.
• Write in plain, direct language — never mannered or ornate prose.

Where you see this

• The session brief. Every activation brief’s “House conventions” section names the standard and its top rules.
• The ch CLI. ch --help prints a “Writing style” paragraph. Every flag that takes freeform prose (--body, --description, --reason, --note, --title) carries the same note in its own --help line. The first time one of those flags resolves to text, ch prints the style hint once to stderr — labeled advisory, stating the text is written unchanged — along with up to two findings, each naming the LINE they occur on. This is never to stdout, so --json output stays clean. Set CH_STYLE_HINTS=0 to turn the hint off.
• The HTTP API. Every /v1/... response carries an X-CodeHerder-Writing-Style header naming the standard.
• MCP. The MCP server sends the full rule list as its instructions at connect time, and the create_task/post_task_comment tools — and their freeform-text fields — carry the same note in their descriptions.

None of this blocks a write. The check behind the CLI hint is advisory: it flags a long sentence, a possible agentive passive-voice marker (a “was rejected by …” construction — not a plain copula like “is untouched” or “is verified”), a sentence that may hold more than one instruction, and a long paragraph — but it never rejects a comment or a task field, and it never rewrites your text. The check measures prose only. It skips a fenced code block, a markdown table row, a heading, and an indented code line. It measures a list one item at a time. So a well-formed list or a pasted command never trips a false finding.

Before and after

Before (long sentence, passive voice, more than one instruction):

The request was rejected by the server because the title field was empty and the description exceeded the length limit and so you will need to shorten it and also add a title before resubmitting.

After (one instruction per sentence, active voice):

The server rejected the request. Add a title. Shorten the description — it is over the length limit.

Before (a negative instruction, dropped article):

Do not forget to not omit reason when you cancel task.

After (a positive instruction, articles restored):

Give a reason when you cancel a task.