Asd Ste100

Scan Checklist

These six habits cover most of what makes machine-written English hard to parse. Each one is mechanical: you can point at the exact word or punctuation mark that breaks the rule, with no judgment call. Scan for all six before you rewrite anything.

1. Synonym rotation — the same thing gets several names in one document ("the user", "the customer", "the client"). The reader cannot tell whether they are one thing or three. Fix: pick one name, use it every time.
2. Hedge stacking — helper verbs and qualifiers pile up until the sentence asserts nothing ("it is important to note that this may potentially help to improve"). Fix: state the claim, or delete it.
3. Nominalization — an action frozen into a noun ("perform an analysis of", "provides assistance to"). Fix: use the verb ("analyze", "helps").
4. Marketing adjectives — words that claim quality instead of showing it: seamless, robust, powerful, cutting-edge, effortless, blazing-fast. Fix: delete, or replace with the measurement that earns the claim.
5. Run-on sentences — several ideas joined by semicolons or em dashes. Fix: one idea per sentence.
6. Soft phrasal verbs — spin up, reach out, dive into, kick off. Fix: use the single plain verb (start, contact, read, begin).

Process

1. Pick the mode (Strict or STE-flavored). Say which only when the user asked for the rule table — see Output Format.
2. Read the input text once for meaning — do not start rewriting before you understand what it must still say afterward.
3. Walk it sentence by sentence. Flag every rule violation from the Core Rewrite Rules tables and every habit from the Scan Checklist. In STE-flavored mode, flag the lexical rules but do not enforce them. For a mechanical first pass over the structural rules, run scripts/ste-lint.py (stdin or file args, --json for structured output); it checks semicolons, sentence length, phrasal verbs, nominalization, marketing adjectives, synonym rotation, dangling-conjunction in supported list items, passive voice, and compound tenses, and by design never flags hedges or modality. --baseline N tolerates N hard violations (for adopting on existing docs); --disable rule1,rule2 silences named rules.
4. Rewrite each flagged sentence to fix the violation while preserving the original meaning exactly. If a rewrite would drop necessary precision (a safety condition, a scope qualifier, a number), keep the longer phrasing and flag it instead of silently simplifying.
   • Check modality before you commit to a rewrite. Hedges ("may", "could", "sometimes", "is likely to") carry the author's confidence, and confidence is content. A shorter sentence that upgrades a hedge to a fact is not a simplification — it is a different claim. This is the most common way a well-intentioned STE rewrite goes wrong, because hedges are exactly what a length cap tempts you to cut.
   • Never add a fact the source did not state. A rewrite that reads better because it supplies a cause, a frequency, or a mechanism has stopped being a rewrite.
5. Output the rewritten text (see Output Format). Keep the mode choice and the rule analysis internal unless the user asked to see them.
6. If the input already complies, say so — do not force changes onto compliant text.

Output Format

Default: the rewritten text, and nothing else. Most callers want a result they can paste straight into a tool description, an error string, or a prompt. Print the simplified text on its own. Do not add a preamble about this skill, a mode announcement, a violation count, a summary of what changed, a rule table, or a closing offer to explain further.

The one permitted addition: if step 4 kept a longer phrasing on purpose, add a single line after the text, prefixed Kept as-is:, naming the phrase and the precision that would have been lost. Omit the line when there is nothing to report.

On request: the rule table. When the user asks to see the reasoning — "show the diff", "which rules did it break", "explain the changes", "before/after" — output this table instead:

| Rule violated | Original | Simplified |
|---|---|---|
| Present perfect tense | "We have received your request." | "We received your request." |
| Noun cluster (4+ words) | "the agent task queue priority handler" | "the handler that sets task-queue priority" |

Mode: Strict. 7 violations found.

Follow the table with a one-line note on anything you deliberately did not simplify, and why (usually: simplifying would lose required precision).

Boundaries

Will:

• Rewrite ambiguous or dense English into short, single-meaning, active-voice sentences.
• Return the rewritten text alone by default, and name the rules it applied when the user asks.
• Preserve every fact, condition, and scope qualifier in the original.
• Preserve the strength of every hedge, and add no claim the source did not make.
• Suggest a one-line glossary entry for domain terms that must stay.

Will not:

• Reproduce ASD's official ~900-word dictionary as if it were memorized verbatim — always treat the official download as the source of truth for exact approved wording.
• Simplify creative, marketing, or persuasive copy where voice and nuance are the point.
• Silently drop a safety condition, exception, or scope qualifier to shorten a sentence — it will flag the trade-off instead.
• Convert "may have failed" into "failed", or "could be caused by X" into "X is the cause" — losing a hedge changes the claim.
• Guarantee an aerospace/defense-grade STE-compliant document. This is a general-purpose clarity tool inspired by STE, not a certified STE authoring tool.
• Make weak content true or useful. STE fixes the form of a text, not its substance. A hollow paragraph rewritten under these rules becomes a clean, short, well-punctuated hollow paragraph. If the text has nothing to say, no rewrite fixes that — say so instead of polishing it.
• Shorten past the point of clarity. Cutting words is not the goal. Removing ambiguity is the goal. Past a certain point compression starts costing the reader time rather than saving it, so stop when the sentence is unambiguous, not when it is shortest.

Additional Resources

• references/writing-rules.md — fuller summary of the 9 rule sections and dictionary structure, with citations to the official standard and secondary sources.
• examples/before-after.md — worked examples, including official STE examples and agent-output examples built for this skill.
• scripts/ste-lint.py — deterministic, stdlib-only linter for the structural rules, including dangling-conjunction in supported list items, plus a synonym-rotation check (one word, one meaning) scoped per file. Exit 1 when hard violations exceed --baseline (default 0); advisory findings (passive voice, compound tenses) never fail the run; --disable silences named rules. It never flags hedges or modality: those are content, not style, and --selftest asserts that "may have failed" passes clean.