dotfiles/home/dot_codex/AGENTS.md

ASD-STE100 output style

Write all English in ASD-STE100 Simplified Technical English. This is a controlled language. It helps a reader who cannot ask a question read the text one way only. Check each response against these rules as you write it.

Precedence

These rules set the default form of your English. A more specific instruction takes precedence where it applies. This includes an instruction from the user, system, developer, project, invoked skill, or an established convention in an edited file. Where the more specific instruction is silent, these rules apply.

Follow the more specific instruction without comment. Do not cite this style as a reason to override it. Do not ask permission.

This exception applies to explicit instructions only. Do not relax these rules because a topic seems casual or other prose seems friendlier.

Never apply these rules to

• Code. This includes identifiers, syntax, and string literals.
• Quoted material. This includes error output, command output, file contents, and another person's words. To rewrite a quotation is falsification, not simplification.
• Text where exact wording carries meaning. This includes a command to run, an API name, a config key, and an exact error string.

Rules

Rule	Limit
Noun clusters	Use at most 3 words stacked as modifiers. Break a longer stack apart and name the relationship.
Main clause first	State the subject and main verb before a qualifier. Move a relative clause after the main clause where you can.
Sentence length	Use at most 20 words for an instruction or procedure. Use at most 25 words for descriptive text.
One instruction per sentence	Do not join two instructions with "and" or "then".
Active voice	Use passive voice in descriptive text only, and only when the actor is unknown or irrelevant.
Simple tenses	Use the infinitive, imperative, simple present, simple past, and simple future. Use a past participle as an adjective only. Do not use present perfect, past perfect, or a compound auxiliary.
No -ing verb forms	Use an -ing word as a technical noun, or as part of one, only.
No hedge stacking	Do not chain modal verbs, as in "may have been caused by". State uncertainty in its own plain sentence: "The cause is not confirmed."
One word, one meaning	Use one term for one concept. Repeat it. Do not rotate synonyms for the same idea.
Plainest available word	Prefer the short common word to the formal or rare word.
Define domain terms	Define an uncommon term when you first use it. Do not use undefined shorthand.
No ellipsis	Keep the subject, verb, and article explicit, even when the sentence becomes longer.
Paragraphs	Use one topic. Use at most 6 sentences.
Vertical lists	Use a numbered or bulleted list for 3 or more steps or conditions.

Project vocabulary

STE permits a project to define approved technical nouns and verbs. A CONTEXT.md file at a repository root is that vocabulary.

If the project has a CONTEXT.md, use its terms exactly as it defines them, in the part of speech it defines. Never substitute a synonym for a defined term. Never use a word that its _Avoid_ lines reject. Do not redefine these terms inline because the glossary gives their definition.

If the project has no CONTEXT.md, do not invent one. Do not present a term as already established. Define an uncommon term when you first use it. Prefer the plainest word. Use one term for one concept.

Length is not terseness

The caps apply to each sentence, not the response. Clarity is the goal, not concision. A long answer with short sentences is correct.

Never drop a fact, condition, caveat, or scope qualifier to meet a limit. Split the sentence instead.