What it does. Check, rewrite, or review technical procedures and descriptions for ASD-STE100-style compliance. Use for manuals, instructions, warnings, maintenance text, technical requirements, and controlled-language reviews. From sourdough-bread/asd-ste100-checker, listed on Agent skills.

Upstream	sourdough-bread/asd-ste100-checker
Skill file	skill/SKILL.md
License	Apache-2.0
Author	sourdough-bread
Fetched	2026-09-10

Install

• npx skills add sourdough-bread/asd-ste100-checker --skill asd-ste100-checker, or copy the skill folder into ~/.claude/skills/asd-ste100-checker/.
• Raw file: curl -sL https://raw.githubusercontent.com/sourdough-bread/asd-ste100-checker/HEAD/skill/SKILL.md

SKILL.md (verbatim)

name: asd-ste100
description: Check, rewrite, or review technical procedures and descriptions for ASD-STE100-style compliance. Use for manuals, instructions, warnings, maintenance text, technical requirements, and controlled-language reviews.

ASD-STE100 Checker Skill

Unofficial — not affiliated with, endorsed by, or sponsored by ASD. ASD-STE100 is a registered European Union Trade Mark (No. 017966390). This skill and the companion MCP/engine are an independent tool. They make no claim of official compliance or certification.

When to use

Use this skill when the user asks to:

• Check or rewrite manuals, procedures, warnings, maintenance text, or technical descriptions for STE-style clarity
• Review controlled language / Simplified Technical English wording
• Look up whether a word is approved and what alternatives exist
• Apply safe synonym fixes before a full rewrite
• Explain what a checker rule_id means and how to fix it
• Check only locally changed documentation files in a git working tree
• Judge Tier-3 semantic WARNINGs (pronouns, topic sentence, POS) via a review brief

Do not use this skill for creative writing, marketing copy, or general English editing unrelated to technical procedures/descriptions.

Core principles

• Prefer short sentences (procedures ≤ 20 words; descriptions ≤ 25 words).
• Use approved dictionary words; prefer project glossary terms when provided.
• Write procedures in active, imperative mood (one instruction per sentence).
• Avoid progressive/perfect/complex verb stacks; keep multi-word nouns ≤ 3 words.
• Name nouns instead of ambiguous pronouns; put the topic in the first descriptive sentence.
• Use each approved word in its approved part of speech only.
• One meaning per word; do not invent alternate senses.
• Preserve identifiers, measurements, part numbers, and safety information.

Strict workflow

1. Multi-file / PR-local docs: call ste_check_changed_files first (working tree vs HEAD, or pass base= for merge-base vs a branch; default globs *.md / *.txt / *.rst / *.adoc).
2. Classify the text as procedure or description (or leave as auto if unsure).
3. Check with MCP: ste_check_text (paste) or ste_check_file (path). Pass a glossary path when available.
4. Treat deterministic ERROR findings as authoritative. Do not dismiss ERROR results based on your own judgment (includes high-confidence STE-POS-MISMATCH).
5. WARNINGs are advisory (Tier-2 parse confidence or Tier-3 semantic heuristics). Prefer fixing them; leave with rationale only if unclear, unless the user asks to clear warnings too.
6. If unsure what a rule_id means, call ste_explain_finding(rule_id).
7. Optionally call ste_apply_safe_fixes first for unambiguous 1:1 synonyms (e.g. utilize → use), then recheck.
8. Call ste_suggest_rewrite to get a structured rewrite brief (prompt + capped findings + constraints + optional safe_fix_preview). It does not call an LLM — you (the host agent) rewrite from that brief.
9. If Tier-3 WARNINGs remain (STE-PRONOUN-AMBIG, STE-TOPIC-SENTENCE, or advisory STE-POS-MISMATCH), call ste_suggest_semantic_review, judge the brief, edit, then recheck.
10. Propose a minimal rewrite using the brief(s). Change only what ERROR findings require (and WARNINGs when requested).
11. Recheck the rewrite with ste_check_text.
12. Stop only when no ERROR findings remain, or explicitly list unresolved findings and why they remain.
13. Never claim certified compliance. Never claim compliance from your rewrite alone without a successful recheck.
14. Preserve part numbers, measurements, identifiers, warnings, cautions, and safety-critical wording unless a finding requires a synonym that does not change meaning.

Canonical loop: check → explain → suggest_rewrite → (optional semantic_review) → host rewrite → recheck.

Details: references/workflow.md

MCP tools

Tool	Use when
ste_check_text(text, text_type="auto", glossary=None, output="json")	Check pasted/generated text; primary loop tool
ste_check_file(path, text_type="auto", output="json")	Check a file on disk
ste_check_changed_files(globs=None, text_type="auto", glossary=None, output="json", base=None)	Check working-tree doc changes vs HEAD, or vs git merge-base HEAD <base>
ste_lookup_word(word)	Inspect status, meaning, alternatives, inflections, rule_ref
ste_explain_finding(rule_id)	Explain a finding’s rule (title, severity, STE ref, fix hints)
ste_apply_safe_fixes(text, glossary=None)	Apply only unambiguous 1:1 synonym replacements; returns text + diff
ste_suggest_rewrite(text, text_type="auto", glossary=None, max_findings=20)	Build a host-agent rewrite brief (prompt-return; no LLM API)
ste_suggest_semantic_review(text, text_type="auto", glossary=None, max_findings=20)	Tier-3-only semantic brief (prompt-return; no LLM API)

spaCy model (MCP)

Check tools do not take a spaCy model parameter. Set STE100_SPACY_MODEL in the MCP server environment before start (default en_core_web_sm).

When to use ste_suggest_rewrite

Call it after you have ERROR (or requested WARNING) findings and before you rewrite with your own LLM. Use prompt as the rewrite instructions; respect constraints. Optionally inspect safe_fix_preview — call ste_apply_safe_fixes only if you want those 1:1 synonyms applied.

When to use ste_suggest_semantic_review

Call it when the check returns Tier-3 findings (especially WARNINGs for pronouns or topic sentence). Use prompt for host judgment; clear POS ERRORs before claiming done. Semantic WARNINGs alone do not make compliant: false.

When to use ste_apply_safe_fixes

Call it before a manual rewrite when findings are mostly vocabulary synonyms with a single clear approved alternative. Do not use it for sentence splits, voice/mood changes, or ambiguous terms—rewrite those yourself, then recheck.

Tier-2 rule IDs

Rule ID	Meaning
STE-PASSIVE	Verbal passive in procedures (Rule 3.6)
STE-IMPERATIVE	Non-imperative procedural step (Rule 5.3)
STE-VERB-FORM	Progressive / perfect / complex verb stack (Rules 3.2 / 3.4)
STE-NOUN-CLUSTER	Multi-word noun longer than 3 words (Rule 2.1)

Tier-3 rule IDs

Rule ID	Meaning
STE-PRONOUN-AMBIG	Ambiguous pronoun (it / this / these / those / they)
STE-TOPIC-SENTENCE	Weak description opener (topic not clear)
STE-POS-MISMATCH	Approved POS clash (verb↔noun / adj↔noun); ERROR if high-confidence

Result shapes: references/result-format.md
Project glossaries: references/terminology-profiles.md

Other files in this skill

• references/result-format.md
• references/terminology-profiles.md
• references/workflow.md

references/result-format.md (verbatim)

Result format

Unofficial tool. Not affiliated with ASD. EU TM No. 017966390.

Primary MCP/CLI output is JSON mirroring ste100/core/schema.py. Optional SARIF is available via output="sarif" on check tools.

Severity meanings

Severity	Meaning	Agent action
error	Determinative Tier-1/Tier-2/Tier-3 violation (high-confidence)	Authoritative. Must fix or explicitly report unresolved.
warning	Likely issue; may be heuristic / lower-confidence Tier-2 or Tier-3	Prefer fixing; may leave with rationale if unclear unless user asks to clear warnings.
info	Advisory / context	Optional; do not treat as compliance failure.

AnalysisResult.compliant is true only when there are no ERROR-level findings (engine definition). Warnings/info alone do not make a text non-compliant in the engine’s boolean.

Tier-2 / Tier-3 findings include evidence keys: confidence, parse_cue, text_type, rule_ref. Call MCP ste_explain_finding(rule_id) for titles, fix hints, and STE mapping.

Tier-2 rule IDs

rule_id	STE ref	Typical scope
STE-PASSIVE	Rule 3.6	procedure
STE-IMPERATIVE	Rule 5.3	procedure
STE-VERB-FORM	Rule 3.2 / 3.4	both
STE-NOUN-CLUSTER	Rule 2.1	both

Tier-3 rule IDs

rule_id	STE ref	Typical scope
STE-PRONOUN-AMBIG	STE pronoun clarity	both
STE-TOPIC-SENTENCE	STE topic sentence	description
STE-POS-MISMATCH	Rule 1.2 / 1.3	both (ERROR if high-conf)

ste_suggest_semantic_review returns Tier-3 findings only, plus a host-agent prompt. Semantic WARNINGs alone do not make compliant false.

Finding

A single located rule violation.

Field	Type	Description
rule_id	string	Stable rule identifier (e.g. vocabulary or sentence rule).
severity	"error" | "warning" | "info"	See table above.
message	string	Human-readable explanation.
start	int	Inclusive UTF-8/codepoint offset into the analyzed text.
end	int	Exclusive offset of the flagged span.
sentence	int | null	0-based sentence index when known.
evidence	object	Rule-specific context (word, count, etc.). Default {}.
suggestions	Suggestion[]	Proposed replacements. Default [].

Suggestion

Field	Type	Description
replacement	string	Proposed text for the span.
confidence	float	0.0–1.0; default 0.0.
automatic	bool	true if suitable for ste_apply_safe_fixes-style auto apply. Default false.

Example Finding (JSON)

{
  "rule_id": "vocabulary.unapproved",
  "severity": "error",
  "message": "Word 'utilize' is not approved; prefer 'use'.",
  "start": 0,
  "end": 7,
  "sentence": 0,
  "evidence": {
    "word": "utilize",
    "status": "unapproved"
  },
  "suggestions": [
    {
      "replacement": "use",
      "confidence": 1.0,
      "automatic": true
    }
  ]
}

AnalysisResult

Full check response for ste_check_text / ste_check_file when output="json".

Field	Type	Description
text_type	"auto" | "procedure" | "description"	Effective classification used for the run (auto may be resolved by the analyzer before rules run; the returned value reflects the type applied).
compliant	bool	true if no ERROR findings.
findings	Finding[]	All findings; may be empty.
summary	object	Aggregates (counts by severity/rule). Default {}.

Example AnalysisResult (JSON)

{
  "text_type": "procedure",
  "compliant": false,
  "findings": [
    {
      "rule_id": "sentence.length",
      "severity": "error",
      "message": "Procedural sentence has 24 words; maximum is 20.",
      "start": 0,
      "end": 118,
      "sentence": 0,
      "evidence": { "word_count": 24, "limit": 20 },
      "suggestions": []
    }
  ],
  "summary": {
    "error": 1,
    "warning": 0,
    "info": 0
  }
}

Related schema types (not always in check output)

These models live in the same schema module; agents may see them via ste_lookup_word or glossary loading, not always in AnalysisResult.

DictionaryRecord (lookup)

Field	Type
word	string
part_of_speech	string
status	WordStatus enum string
approved_meaning	string | null
inflections	string[]
alternatives	string[]
category	string | null
rule_ref	string | null
examples_ste / examples_non_ste	string[]
notes	string | null

WordStatus values: approved, unapproved, forbidden, technical_noun, technical_verbs, not_approved_technical_verb.

Glossary (YAML profile → engine)

Field	Type
name	string
technical_nouns	GlossaryEntry[]
technical_verbs	GlossaryEntry[]
preferred_terms	map[string, string]

See terminology-profiles.md.

SARIF note

When output="sarif", the same findings are serialized as a SARIF 2.1.0 log suitable for CI upload / code-scanning UIs.

• Each Finding maps to a SARIF result (ruleId ← rule_id, level from severity).
• Offsets map to a physical location on the analyzed artifact.
• Prefer JSON for the agent rewrite loop; use SARIF for tooling pipelines.

Severity → SARIF level (typical mapping):

Severity	SARIF level
error	error
warning	warning
info	note

Exact SARIF field layout is owned by ste100/core/serialize.py; treat this section as contract intent, not a second schema.

references/terminology-profiles.md (verbatim)

Terminology profiles (project glossaries)

Unofficial tool. Not affiliated with ASD. EU TM No. 017966390.

Pass a glossary YAML path to ste_check_text / ste_apply_safe_fixes via the glossary argument so project-specific nouns, verbs, and preferred terms are recognized during checks and safe fixes.

The engine loads YAML into the Glossary model from ste100/core/schema.py.

File shape

name: <profile-name>          # required string

technical_nouns:              # optional list
  - word: <lemma>
    part_of_speech: noun      # default: noun
    status: technical_noun    # default: technical_noun
    approved_meaning: <str>   # optional
    inflections: []           # optional list of surface forms
    preferred_term: <str>     # optional canonical display form

technical_verbs:              # optional list
  - word: <lemma>
    part_of_speech: verb
    status: technical_verbs   # default for verbs when set explicitly
    approved_meaning: <str>
    inflections: []
    preferred_term: <str>

preferred_terms:              # optional map: dispreferred → preferred
  <unwanted-form>: <preferred-form>

Field notes

Key	Purpose
technical_nouns	Product/domain nouns not in (or extending) the STE dictionary.
technical_verbs	Approved technical verbs for this project.
preferred_terms	Unambiguous 1:1 renames; safe-fixes may apply these.
inflections	Plural/tense forms the engine should treat as the same entry.
preferred_term	Optional canonical spelling for that entry.
approved_meaning	Single allowed sense; agents must not invent other senses.

Keep glossaries minimal. Only add terms the project truly needs. Prefer STE approved words when they already cover the meaning.

preferred_terms must be 1:1 and unambiguous (same referent, no context branching). Ambiguous mappings belong in agent rewrite judgment, not safe-fixes.

Worked example

File: glossaries/landing-gear.yaml

# Project terminology for landing-gear maintenance manuals.
# Unofficial STE checker profile — not an ASD publication.

name: landing-gear-maintenance

technical_nouns:
  - word: torque-link
    part_of_speech: noun
    status: technical_noun
    approved_meaning: The link that connects the landing gear oleo to the axle.
    inflections:
      - torque-links
    preferred_term: torque-link

  - word: oleo
    part_of_speech: noun
    status: technical_noun
    approved_meaning: The shock absorber strut of the landing gear.
    inflections:
      - oleos

  - word: bogie
    part_of_speech: noun
    status: technical_noun
    approved_meaning: The multi-wheel truck assembly of the main landing gear.
    inflections:
      - bogies

technical_verbs:
  - word: safeties
    part_of_speech: verb
    status: technical_verbs
    approved_meaning: Installs a safety device or lock to prevent unwanted movement.
    inflections:
      - safety
      - safetied
      - safetying
    preferred_term: safety

preferred_terms:
  utilize: use
  ensure: make sure
  torque link: torque-link
  shock strut: oleo

How to use with MCP

ste_check_text(
  text=<manual excerpt>,
  text_type="procedure",
  glossary="glossaries/landing-gear.yaml",
  output="json",
)

ste_apply_safe_fixes(
  text=<manual excerpt>,
  glossary="glossaries/landing-gear.yaml",
)

Expected effect

• torque-link / oleo / bogie are accepted as technical nouns (not flagged as unapproved vocabulary solely for being absent from the base dictionary).
• utilize → use and similar preferred_terms entries are candidates for ste_apply_safe_fixes.
• Agent rewrites must keep the approved_meaning of glossary terms and must not substitute unrelated synonyms for safety-critical nouns.

Authoring checklist

1. One profile per product family or manual set (name unique and stable).
2. Lemmas lowercase unless the term is a required mixed-case identifier.
3. List needed inflections; do not rely on guessing irregular forms.
4. Put only clear synonyms in preferred_terms.
5. Re-run ste_check_text after glossary edits—do not assume compliance without a recheck.

references/workflow.md (verbatim)

Rewrite / recheck workflow

Unofficial tool. Not affiliated with ASD. EU TM No. 017966390.

This document expands the skill workflow. The engine is deterministic; you (the agent) rewrite with your own LLM, then recheck via MCP.

0. Multi-file first pass

When the user asks about changed docs, a PR, or “what I edited locally”:

1. Call ste_check_changed_files (or CLI ste100 check-changed).
2. It compares the working tree to HEAD (staged + unstaged + untracked).
3. Default globs: *.md, *.txt, *.rst, *.adoc (override with globs / --glob).
4. Aggregate compliant is true only when every matched file has no ERROR findings.
5. Then drill into individual files with ste_check_file / ste_suggest_rewrite as needed.

Requires a git repository. If not in a repo, the tool returns a clear error.

1. Classify: procedure vs description

Signal	Prefer procedure	Prefer description
Mood	Imperative verbs, numbered steps	Declarative statements
Purpose	Tell the reader what to do	Explain what something is/does
Typical headings	Procedure, Removal, Installation, Warning	Description, Overview, Function

If mixed, set text_type to the dominant type for the span you are checking, or use auto and accept the analyzer’s choice.

Pass the classification into ste_check_text / ste_check_file / ste_suggest_rewrite as text_type.

2. Sentence length limits (Tier-1)

Text type	Max words per sentence
Procedure	20
Description	25

Count words in the English sentence the engine segments. Split long sentences; do not pack multiple instructions into one procedural sentence.

Procedure — too long / multi-instruction

Remove the cover and disconnect the cable and inspect the connector for damage.

Rewrite (one instruction per sentence, ≤ 20 words):

Remove the cover.
Disconnect the cable.
Inspect the connector for damage.

Description — too long

The hydraulic pump supplies pressure to the landing gear system and also provides backup pressure to the brake system during emergency operation.

Rewrite (≤ 25 words each):

The hydraulic pump supplies pressure to the landing gear system.
It also supplies backup pressure to the brake system during emergency operation.

2b. Tier-2 syntax (deterministic)

Rule ID	Fix approach
STE-PASSIVE	Rewrite procedures in active voice / imperative. Past participles used as adjectives (Rule 3.3) are not errors.
STE-IMPERATIVE	Numbered steps must be commands (Close the valve.).
STE-VERB-FORM	Drop progressive/perfect/modal+passive; use approved simple forms.
STE-NOUN-CLUSTER	Keep multi-word nouns to ≤ 3 words.

Call ste_explain_finding(rule_id) when a finding’s meaning is unclear. ERRORs are authoritative; WARNINGs are advisory unless the user asks to clear them.

Evidence on Tier-2 findings includes confidence, parse_cue, text_type, and rule_ref.

2c. Tier-3 semantic (hybrid heuristics)

Rule ID	Scope	Fix approach
STE-PRONOUN-AMBIG	both	Name the noun instead of it / this / these / those / they when the prior sentence has no clear antecedent or multiple candidates.
STE-TOPIC-SENTENCE	description only	Put the topic noun in the first sentence; avoid pronoun/demonstrative starts, fragments, pure coordination, and meta-comments.
STE-POS-MISMATCH	both	Use the approved dictionary part of speech (verb↔noun / adj↔noun). High-confidence clashes are ERRORs; TN/TV and unapproved words are skipped (vocab owns them).

Default severity is WARNING. Only high-confidence approved POS clashes escalate to ERROR.

After check, if Tier-3 WARNINGs remain → call ste_suggest_semantic_review → host judgment → recheck. POS ERRORs still go through the rewrite path and must clear before claiming done.

3. Check → explain → suggest_rewrite → (semantic_review) → host rewrite → recheck

(optional) ste_check_changed_files   # multi-file / local changes
   ↓
classify
   ↓
ste_check_text / ste_check_file
   ↓
ERROR findings?
   ├─ no  → if Tier-3 WARNINGs → ste_suggest_semantic_review → host edit → recheck
   │         else report “no ERROR findings on recheck” (still unofficial; not certified)
   └─ yes → optional ste_explain_finding
              ↓
            optional ste_apply_safe_fixes (1:1 only) + recheck
              ↓
            ste_suggest_rewrite  → use returned prompt (host LLM; no API in MCP)
              ↓
            host produces minimal rewrite
              ↓
            (optional) ste_suggest_semantic_review for remaining Tier-3 WARNINGs
              ↓
            ste_check_text again
              ↓
            remaining ERRORs?
              ├─ no  → done
              └─ yes → repeat suggest_rewrite / rewrite / recheck
                         OR report unresolved findings

Rules for each rewrite pass

1. Treat every severity: "error" finding as must-fix unless you cannot without changing safety meaning—then report it unresolved.
2. Prefer the finding’s suggestions when present and high-confidence.
3. Change the smallest span that clears the finding.
4. Do not “improve” style beyond what findings require.
5. Prefer ste_suggest_rewrite over ad-hoc prompting; follow its constraints.
6. Prefer ste_suggest_semantic_review for Tier-3 WARNINGs; follow its constraints.
7. After every rewrite (including safe-fixes), call ste_check_text again.
8. Never claim compliance from an unchecked rewrite.
9. Treat warning as advisory unless the user asks to clear warnings.

4. Vocabulary and glossary

• Unapproved / forbidden words → replace with approved alternatives from the finding or ste_lookup_word.
• Project glossary terms override or extend the dictionary when a glossary path is passed.
• Prefer glossary preferred_terms mappings when both forms appear.

5. Preserve always

Do not alter unless a finding explicitly requires a synonym that keeps the same referent:

• Part numbers, serial numbers, document IDs, software identifiers
• Numeric values and units (e.g. 5 mm, 120 °C)
• Warning / Caution / Note labels and safety-critical conditions
• Proper names required by the product or regulation

6. Stopping criteria

Done: recheck returns compliant: true or zero ERROR findings.

Stop with report: remaining ERRORs that you cannot clear without inventing data or changing safety meaning. List each unresolved finding (rule_id, span/evidence, reason).

Forbidden: claiming certified ASD-STE100 compliance; claiming the text is compliant because you rewrote it without a successful MCP recheck.

7. Example end-to-end

Input (procedure):

Utilize a torque wrench to carefully tighten the bolts and then check them.

1. Classify → procedure
2. ste_check_text(..., text_type="procedure") → errors for utilize, sentence length / multi-instruction
3. Optional: ste_explain_finding / ste_apply_safe_fixes may yield Use a torque wrench... still multi-instruction
4. ste_suggest_rewrite → use prompt + constraints
5. Minimal rewrite:

Use a torque wrench to tighten the bolts.
Then check the bolts.

6. ste_check_text on the rewrite → no ERROR findings → report rewrite + note that results are unofficial / not certified.

Input (Tier-2 passive step):

1. The valve is closed by the operator.

1. Classify → procedure
2. Check → STE-PASSIVE / STE-IMPERATIVE ERRORs (call ste_explain_finding if needed)
3. ste_suggest_rewrite → host rewrite → 1. Close the valve.
4. Recheck → no ERROR findings for those rules

Input (Tier-3 ambiguous pronoun):

Remove the panel from the unit. It is damaged.

1. Classify → description
2. Check → STE-PRONOUN-AMBIG WARNING (compliant may still be true)
3. ste_suggest_semantic_review → host names the noun → The panel is damaged.
4. Recheck → no Tier-3 findings for that span

Back to Agent skills.