Why the agent writes Simplified Technical English

A reply that takes three reads costs a round trip. Tarsk tells the assistant to write in Simplified Technical English, a controlled form of English that aircraft manuals use for instructions. Replies come back shorter, plainer and closer to the action they describe.

A standard built for instructions

Simplified Technical English is a real standard: ASD-STE100, written by the aerospace industry for maintenance documentation. Issue 9 runs to 53 writing rules and a dictionary of about 900 approved words, plus the technical nouns and verbs that each company adds for its own field.

The dictionary keeps one word for one meaning, with one part of speech. Where English offers several synonyms, STE keeps a single one. Start is approved. Begin, commence and initiate are not. A reader never has to wonder whether two words mean the same thing.

The rules set limits a person can check:

• 20 words in a procedure step, 25 in a description, 25 in a note.
• 6 sentences in a paragraph.
• Active voice, with the actor named.
• The imperative for an action: “Run the tests”, not “The tests should be run”.
• One instruction per sentence.

A mechanic reads a maintenance step with dirty hands and no time to parse it. A developer reads an agent reply between two other tasks, with the same constraint.

One line in the instructions

Tarsk adds a single sentence to the assistant’s standing instructions: talk in ASD-STE100 Simplified Technical English. It sits with the house rules that already say to answer directly, skip the preamble, avoid emojis and stop before unsolicited follow-ups. The agent reads it on every turn of every chat, in the app and on iOS.

You can read the whole thing. Open Settings > System Prompt and the page shows the generated prompt for the current project. The Generated toggle decides whether the project uses that text or your own override. Edit the text, press Save, and confirm the overwrite dialog if you replace a custom prompt with the default.

The same question, two answers

Two runs of the assistant got the same request: explain in three sentences why each chat needs its own working copy of a repository. One run had a plain style instruction. The other had the STE rule.

Plain style, 82 words, sentences of 25, 29 and 28 words:

Because chats run concurrently and often leave uncommitted edits, branches, and generated artifacts behind, sharing one checkout lets one chat’s half-finished work silently corrupt another’s. A private working copy also gives each chat its own build, test, and index state, so a broken intermediate step in one conversation can’t break commands running in another. Finally, it creates a clean diff-and-discard boundary: you can review what a chat changed, or throw it away entirely, without disturbing the main checkout or any other conversation.

With the STE rule, 74 words, sentences of 22, 28 and 24 words:

Each chat needs its own working copy so that its uncommitted edits, build outputs, and test runs stay isolated from other chats. Two chats in the same copy would overwrite each other’s files and give false test results, and a failed change could damage work that is not saved yet. A separate copy also lets you discard one chat’s changes without risk to the main repository or to the work of the other chats.

Both answers are correct. The difference shows up in the reading. The plain version hides the actor inside “sharing one checkout lets one chat’s half-finished work silently corrupt another’s”. The STE version puts two chats in a copy and says what happens: they overwrite each other’s files. The phrase “diff-and-discard boundary” becomes “discard one chat’s changes”.

What changes in a reply

Steps arrive numbered, one action per sentence, with the verb first. A task that needs four actions gets four lines instead of one long clause.

The same word covers the same thing from the first line to the last. If the reply says thread, the next paragraph does not switch to workspace.

An error names what failed and the step that follows. The model states the cause and the fix in separate sentences, so a reader can act on the second one without decoding the first.

Long clauses turn into lists. Where ordinary prose would stack three conditions into a sentence, the reply gives each condition its own line.

What you give up

Tone goes first. Jokes, hedges and emphasis do not survive the word list, and a reply about a tricky bug reads flatter than the same reply in ordinary prose.

Nuance suffers in the same move. A long causal chain becomes several short sentences, which is clearer for an action and weaker for an argument. A design discussion that needs caveats will read more mechanical than the thinking behind it deserves.

Repetition goes up. The rule prefers the same noun to a pronoun or a synonym, so a paragraph about a task repeats the word task.

No check runs before a reply reaches you. The STE sample above has a middle sentence of 28 words, past the 25-word limit for descriptive text. Long answers, quoted logs and tables can drift back into ordinary prose.

It is also English only. A chat in another language gets the house rules for concision and none of the dictionary.

Change the voice

Open Settings > System Prompt, turn Generated off, write your own instruction, and press Save. The change applies to that project only, so a writing project can keep a looser voice while a code project keeps the rule.

Bots carry a version of the same line in their own prompt, because a Bot passes prompts to Projects and needs the same discipline when it writes the handoff.

Bottom line

• Simplified Technical English is a rule set and a word list you can check.
• The agent reads it on every turn, so replies arrive as steps with named actors.
• The cost is tone and nuance, and a project can trade the rule away in Settings.

Open a chat and ask for the next step in a task you are already doing. The reply will tell you what to run, in the order to run it.