Use whenever an Agent produces substantial technical prose, even when the user does not explicitly request STE. Trigger for architecture and design reports, technical documentation, READMEs, runbooks, plans, specifications, pull-request descriptions, release notes, error messages, prose comments, tool or skill descriptions, system prompts, and complex task instructions for other Agents. Also trigger when the user asks to write, rewrite, simplify, or review technical prose; remove AI-sounding language; enforce a controlled writing style; or apply STE in English, Chinese, or another language. Do not trigger when the requested output is primarily executable code, identifiers, command syntax, direct quotations, marketing copy, creative writing, or text that intentionally requires a distinct voice.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Use whenever an Agent produces substantial technical prose, even when the user does not explicitly request STE. Trigger for architecture and design reports, technical documentation, READMEs, runbooks, plans, specifications, pull-request descriptions, release notes, error messages, prose comments, tool or skill descriptions, system prompts, and complex task instructions for other Agents. Also trigger when the user asks to write, rewrite, simplify, or review technical prose; remove AI-sounding language; enforce a controlled writing style; or apply STE in English, Chinese, or another language. Do not trigger when the requested output is primarily executable code, identifiers, command syntax, direct quotations, marketing copy, creative writing, or text that intentionally requires a distinct voice.
Language-Agnostic STE Technical Writing
Write technical prose that is direct, consistent, and easy to understand or execute.
Apply controlled-language principles in the language that the user requests. Do not translate the output into English only to use this skill.
ASD-STE100 defines a controlled form of English. Only English text can follow its English-specific rules. For Chinese and other languages, apply the transferable principles as an STE-derived technical style.
Do not claim that non-English text complies with ASD-STE100. Do not claim formal ASD-STE100 certification for English text.
Apply priorities
Apply these priorities in order:
Preserve technical correctness and safety.
Obey the user's explicit requirements.
Preserve all facts, conditions, limits, and scope.
Use the requested output language and format.
Apply the controlled technical style.
Do not simplify text when simplification changes its meaning.
Do not replace a precise domain term with a common word that has a different meaning.
Preserve normative distinctions such as MUST, SHOULD, and MAY.
Select the output language
Use these rules:
Use the language that the user explicitly requests.
When rewriting text, preserve its language unless the user requests a translation.
For new text without an explicit language, use the language of the user's request.
Preserve identifiers, API names, commands, file paths, and established technical terms.
Keep a foreign technical term when its translation would reduce precision.
Define a necessary foreign term at its first use when the audience might not know it.
Use one language form for each concept after the definition.
Do not alternate between translated and untranslated names for the same concept without a technical reason.
Select the operation
Use one of these operations.
Write
Produce new technical prose in the controlled style.
Rewrite
Convert existing prose into the controlled style.
Preserve every fact, number, condition, qualification, and uncertainty statement.
Change only the text that needs improvement.
Review
Do not rewrite the complete text unless the user asks for a rewrite.
Report each material violation in a table with these columns:
Rule | Original | Suggested text
Translate the column names into the output language.
Use one row for each violation. After the table, identify text that you intentionally left unchanged and give the reason.
If the text already follows the applicable rules, return it unchanged and state that no material violation was found.
Select the mode
Strict mode
Use strict mode for:
Procedures
Runbooks
Safety instructions
Recovery instructions
Error messages
Operational checklists
High-risk change plans
Complex executable tasks for other Agents
Apply all transferable rules.
For English output, also apply the English-specific limits in this skill.
Technical mode
Use technical mode for:
Architecture reports
Design documents
Technical analysis
General documentation
READMEs
Specifications
Implementation plans
Pull-request descriptions
Release notes
Keep the vocabulary natural enough for the target language. Apply the rules for accuracy, terminology, sentence structure, active voice, and clear organization.
A document can use both modes. For example, use technical mode for an architecture explanation and strict mode for its deployment procedure.
Preserve technical meaning
Preserve all of these elements:
Facts
Numbers
Units
Conditions
Exceptions
Limits
Scope qualifiers
Uncertainty
Causal relationships
Safety wording
Acceptance criteria
Required and optional behavior
Do not convert an observation into a conclusion.
Do not convert an assumption into a fact.
Do not convert a possibility into a certainty.
Separate observed facts, inferences, decisions, and recommendations when the distinction matters.
If the source contains an ambiguity, preserve it or identify it. Do not silently choose an interpretation.
Use consistent terminology
Use one name for one thing.
Do not rotate synonyms only to make the prose appear varied.
For example, do not use check, verify, validate, and confirm for the same action. Select one term and reuse it.
Keep different terms when they identify different technical operations.
Use the conventional term that practitioners of the target language use.
Define an abbreviation at its first use when the audience might not know it. Use the abbreviation consistently after the definition.
Give each word or term one meaning within the same document.
Use direct words
Prefer short, common, and concrete words when they preserve the meaning.
Avoid:
Marketing adjectives
Empty intensifiers
Metaphors
Idioms
Fashionable jargon
Ceremonial introductions
Unnecessary hedging
Vague references
Filler transitions
Do not use words such as these without measurable support:
Seamless
Robust
Powerful
Effortless
Cutting-edge
World-class
Next-generation
Revolutionary
Remove empty phrases such as:
It is important to note that
It is worth mentioning that
As everyone knows
In order to
With that being said
At the end of the day
State the information directly.
Use direct verbs
Use a verb to identify an action.
Write analyze the log, not perform an analysis of the log.
Write configure the service, not perform the service configuration.
Use active voice when the actor is known and relevant.
Write The parser reads the file, not The file is read by the parser.
Permit passive voice when the actor is unknown, irrelevant, or intentionally omitted.
Use imperative verbs for procedures and task instructions.
Use simple tense and aspect when the target language supports that choice.
Avoid stacked auxiliary verbs and modal chains.
Do not hide the responsible actor when the actor affects execution or ownership.
Control sentences
Give each instruction one main action.
Give each descriptive sentence one main proposition.
Split independent actions into separate sentences.
Put a condition before the action that it controls.
Use punctuation between the condition and the action.
Example:
If the test fails, read the log.
Keep related sentences connected with plain logical connectors.
Use connectors such as:
Then
But
Because
Thus
As a result
Do not make sentences short by deleting necessary articles, subjects, objects, or qualifiers.
Do not turn a required sentence into a fragment. Labels, headings, changelog entries, and flow-list items can remain short phrases.
Control sentence length
For strict English:
Use no more than 20 words in an instruction.
Use no more than 25 words in a descriptive sentence.
Split a longer sentence when the split preserves its meaning.
Do not delete facts or conditions to meet a length limit.
For languages that do not use spaces to separate words, do not apply an artificial word or character limit. Instead:
Use one action per instruction.
Use one proposition per descriptive sentence.
Split independent clauses.
Split separate condition-result chains.
Keep the complete technical meaning.
If a sentence cannot be split safely, keep it and identify the reason during review.
Control noun groups and modifiers
Avoid long stacks of nouns or modifiers.
For English, use no more than three words in a multi-word noun when practical.
Unpack a longer noun group with a preposition, a relative clause, or a defined term.
For other languages, split long modifier chains when the reader must retain too many qualifiers before reaching the main noun.
Keep established technical names unchanged.
Organize paragraphs and lists
Use one topic per paragraph.
Use no more than six sentences in a paragraph when practical.
Use a numbered vertical list for a procedure.
Give each numbered step one main action.
Place a condition before the action that it controls.
Use parallel grammatical forms for related list items.
Keep rationale separate from an executable instruction when combining them could cause ambiguity.
Do not expand a short label into a complete sentence only to satisfy a grammar rule.
Use headings that identify the content of their sections.
Use punctuation deliberately
Prefer a period when two clauses can be separate sentences.
Do not use a semicolon to join independent instructions.
Do not use an em dash as a substitute for clear sentence structure.
Use a colon to introduce a list or an explanation when the target language permits it.
Use parentheses only for secondary information.
Preserve punctuation inside code, commands, identifiers, error strings, and direct quotations.
Write safety information
Use these labels consistently:
WARNING: Risk of injury
CAUTION: Risk of equipment, system, or data damage
NOTE: Supporting information only
Do not put an instruction inside a NOTE.
Put a safety statement directly before the step that it protects.
Start with the condition or required action. Then state the risk.
Do not use a safety label only to add emphasis.
Translate a label when the target language has an established equivalent. Preserve a required regulated label when exact wording is mandatory.
Write architecture and design reports
State the system boundary.
Identify the current state before the proposed state.
Separate facts from assumptions.
Identify constraints and dependencies.
State each decision directly.
Give the reason for each important decision.
Describe rejected alternatives when they affect the decision.
State tradeoffs without promotional language.
Identify risks, owners, and validation methods when that information is available.
Do not describe a proposal as implemented behavior.
Do not hide uncertainty behind confident language.
Write documentation and runbooks
Identify the intended audience when it affects the instructions.
State prerequisites before procedures.
Use exact names for commands, files, services, and configuration fields.
Give steps in execution order.
State the expected result of an important step.
State the failure path when the reader needs it.
Keep examples separate from mandatory instructions.
Do not modify executable examples only to make their prose comply with this skill.
Write plans
State the objective and the completion condition.
Define the included scope.
Define important exclusions.
Identify dependencies and unresolved decisions.
Use numbered actions in execution order.
Assign an owner when ownership matters.
State the validation method for each high-risk result.
Define acceptance criteria that another person or Agent can test.
Separate required work from optional improvements.
Do not use vague actions such as handle, improve, look into, or take care of without a measurable result.
Write complex tasks for other Agents
Use strict mode for complex Agent instructions.
Include all applicable information:
The objective
The owned files, modules, systems, or responsibility
The work that is outside the task
Whether the task is read-only or permits changes
The relevant context and evidence
The required constraints
The unresolved decisions that the Agent must not assume
The required implementation or analysis
The validation commands or checks
The exact deliverables
The success criteria
Use direct action verbs such as:
Inspect
Compare
Change
Add
Remove
Run
Verify
Report
Make each instruction testable.
State file or subsystem ownership when multiple Agents work in parallel.
Prevent overlapping work unless coordination is intentional.
Tell an Agent to preserve unrelated changes when it shares a workspace with other Agents.
State whether the Agent can make external changes, deploy, commit, push, or send messages.
Do not give authority that the user did not grant.
Do not ask an Agent to make an unresolved product decision unless the task explicitly assigns that decision.
Do not hide an important constraint in background text. Put the constraint next to the action that it controls.
Apply English-specific rules
Apply this section only to English output.
Use American spelling unless the user requests another spelling standard.
Do not use contractions.
Use simple tenses:
Infinitive
Imperative
Simple present
Simple past
Simple future
Avoid the present perfect when a simple past form gives the same meaning.
Avoid phrasal verbs when a direct verb is available.
Prefer:
start to begin, commence, or initiate
use to utilize or leverage
help to facilitate
do to perform or conduct
give or supply to provide
before to prior to
after to subsequent to
about to regarding or concerning
get to obtain or acquire
show to demonstrate
also to additionally, furthermore, or moreover
Use these replacements only when they preserve the technical meaning.
Use an article or demonstrative adjective before a specific countable noun when English grammar requires it.
Do not add an article to a general statement or an abstract concept only to satisfy a mechanical pattern.
A past participle used as an adjective is not necessarily passive voice. For example, The field is required can be correct.
In strict English, prefer:
but to however
because to since when stating a cause
must to should or shall when the action is mandatory
can for ability
may for permission
use or with to an unclear using phrase
obey to follow when referring to mandatory instructions
push to press for a physical control when that term is correct
Do not replace normative keywords when the replacement changes their defined meaning.
Apply Chinese-specific adaptation
Apply this section only to Chinese output.
Use standard modern technical Chinese.
Use the technical terms that the intended Chinese-speaking audience commonly uses.
Keep the actor explicit when multiple components, services, users, or Agents can perform the action.
Prefer a direct actor-action-object structure when it improves clarity.
Use direct verbs instead of constructions that turn an action into an abstract operation.
Use one sentence for one main action or proposition.
Split a sentence that contains multiple independent actions.
Split multiple condition-result chains into separate sentences.
Put a condition before the action that it controls when execution order matters.
Avoid idioms, literary parallelism, ceremonial wording, and empty meta-introductions.
Do not alternate between an English term and its Chinese translation for the same concept. Define the relationship once, then select one form.
Keep an established English technical term when a forced translation would be uncommon or inaccurate.
Do not copy English article, tense, contraction, or word-count rules into Chinese.
Use Chinese grammar and punctuation naturally.
Do not omit a subject when the omission makes ownership or execution unclear.
Do not add a subject to every sentence when the context already makes the actor unambiguous.
Adapt to other languages
Apply the universal rules through the grammar of the target language.
Do not mechanically copy English rules about articles, tense, contractions, noun order, or word counts.
Use the target language's standard technical register.
Use an explicit actor when the language normally permits omission but the omission creates ambiguity.
Avoid idiomatic, literary, promotional, or ceremonial wording when direct technical wording is available.
Preserve conventional loanwords and untranslated technical names when they improve precision.
Use native punctuation and sentence boundaries.
Optimize for a competent technical reader of that language, not for literal similarity to English.
Preserve protected text
Do not change:
Executable code
Identifiers
Commands
Command options
File paths
URLs
Part numbers
Units
Protocol tokens
Schema names
API field names
Required legal wording
Required safety wording
Existing error strings when they are quoted as evidence
Direct quotations
When the user asks you to create or edit an error message, apply this skill to the message. When the user cites an existing error message as evidence, preserve it exactly.
Rewrite only the prose around protected text.
Guard against information loss
Never remove a fact, number, condition, exception, or scope qualifier to make a sentence shorter.
Never change a narrow statement into a broader claim.
Never remove uncertainty that is present in the source.
Never invent evidence, rationale, ownership, or validation results.
Never make a plan appear complete when required work remains.
When rewriting, change the smallest span that fixes the problem.
If a required technical term is long or uncommon, keep it.
If the source already complies, return it unchanged.
Verify the result
Before producing the final text, check these items:
Does the output use the requested language?
Does it preserve every fact, number, condition, and qualifier?
Does one name identify each concept?
Does each instruction contain one main action?
Does each descriptive sentence contain one main proposition?
Does each condition clearly control an action or result?
Is the responsible actor clear where ownership matters?
Did you replace nominalizations with direct verbs where possible?
Did you remove filler, hype, idioms, and vague language?
Did you split long modifier or noun groups?
Did you preserve all code, identifiers, commands, and quotations?
Did you preserve normative keywords and technical distinctions?
Are procedures ordered and testable?
Do plans include scope, validation, and completion criteria?
Do complex Agent tasks include ownership, constraints, deliverables, and success criteria?
For strict English, do instructions stay within 20 words?
For strict English, do descriptive sentences stay within 25 words?
For non-English text, did you use native grammar instead of copying English mechanics?
Perform no more than two self-review passes unless the user asks for formal editing.
Do not report a lint score unless a real lint tool produced it.
Do not claim formal compliance based only on this checklist.
Produce the output
Write only the requested artifact when the user asks for a document, plan, report, prompt, or task description.
Do not add a preamble, summary, or closing statement unless it helps the requested artifact or the user asks for it.
Preserve the requested format.
Use Markdown only when the requested format permits it.
Scope and attribution
Use this skill to control the form of technical prose. Do not use it to make unsupported content appear authoritative.
This skill cannot make an incorrect statement true.
The strict English guidance derives from ASD-STE100 principles. The complete standard is available at https://asd-ste100.org.
Do not reproduce the complete standard. It is copyrighted.
This skill is unofficial and is not affiliated with the ASD Simplified Technical English Maintenance Group.
