概要
曖昧な英文を ASD-STE100 簡易技術英語ルールで書き換え、下流の AI エージェントが誤読しないようにする Claude Code スキル。文ごとに違反をマークし、事実を失うことなく書き直すとともに、決定論的な Python チェッカーを付属して構造検証を行う。厳格な手順と説明的テキストの2つのモードをサポートする。
README プレビュー
# ASD-STE100 Skill — Simplified Technical English for Agent Output\n\nA Claude Code skill that rewrites dense, ambiguous English into [ASD-STE100 Simplified Technical English](https://www.asd-ste100.org/) (STE) — the controlled-language standard the aerospace and defense industry built so aircraft maintenance instructions cannot be misread.\n\nThis skill repurposes that same discipline for a different reader: an **AI agent** parsing another agent's output, a tool description, an error message, or an inter-agent instruction, with no human in the loop to resolve ambiguity.\n\n## Why STE, and Why for Agents\n\nSTE exists because a misread instruction on an aircraft can kill people, and the intended readers were often not native English speakers with no author to call for clarification. The standard's fix: one meaning per word, active voice, simple tenses, one instruction per sentence, short sentences, no dropped words.\n\nAn LLM agent parsing another agent's output is in a strikingly similar position — no back-channel, no way to ask "did you mean X or Y?" The same rules that keep a mechanic from misreading a torque spec keep a downstream agent from misreading a tool description or an inter-agent message.\n\n## Before / After\n\n| Before | After |\n|---|---|\n| "This tool will attempt to synchronize state across the various backends that have been configured, and if a conflict is detected it may resolve it automatically depending on the strategy that has been set, or otherwise it will surface the conflict for manual review." | "The tool tries to synchronize state across the configured backends. If it finds a conflict, it reads the configured strategy. If the strategy allows automatic resolution, the tool may resolve the conflict without a user. If the tool does not resolve the conflict, it reports the conflict for manual review." |\n| "An error may have occurred while processing your request due to a possible mismatch in the expected data format, which could be caused b
FAQ (3)
トラブル対応なぜ ASD-STE100 リンターは Markdown テーブルを長すぎる文としてフラグを立てるのですか？
これは splitter のバグで、PR #14 で修正済みです。linter が prose stream から markdown テーブルを除去していませんでした。テーブルの行は文末の句読点ではなく | で終わるため、ヘッダー + 区切り + データ行が1つの「文」に結合され、すべての | と --- トークンが単語としてカウントされ、25語の文制限を超えてカウントが水増しされていました（例：通常のテーブルが122「語」とカウントされる）。最新バージョンに更新してください。テーブルの構造トークンはカウントされなくなり、セル内の実際の違反は引き続き検出されます。古いバージョンでの回避策：（1）各行の最後のセルをピリオドで終わらせ、splitter が行ごとに分割されるようにする、または（2）テーブルを縦の箇条書きリストに変換し、1行につきピリオドで終わる1項目にする——2項目を超えるリストについては ASD-STE100 がいずれにせよこれを推奨しています。
トラブル対応examples/before-after.md の単語数がサンプルテキストと一致しないのはなぜですか？
記載されている4つのカウントのうち3つが誤っています。空白分割を用いた正しいカウントは次のとおりです: Example A(ツールの説明)= 55ではなく44語、Example C(エージェント間の指示)= 42ではなく36語、Example D(READMEの散文)= 36ではなく34語。Example B(エラーメッセージ)のみが28語で正しいものです。すべての判定は依然として成立します。どの例も引用されている上限(25語の説明上限、20語の指示上限)を超えたままであるため、'After'のテキストではなく数字だけを修正すればよいです。Pythonでlen(text.split())を使って、任意のカウントを自分で検証できます。ファイルにはカウント方法が記載されていないことに注意してください: これらの数字は、句読点をカウントせず空白で区切られたトークンを前提としているため、'lock-in'のようなハイフン付きの単語を分割するトークナイザーでは異なる結果になります。関連して、同じファイルの43行目(PR #7で残されたプロジェクト自身の散文)には、リポジトリ自身のRule 8.1に違反するセミコロンが含まれており、削除すべきです。
トラブル対応なぜ README の Before/After テーブルは examples/before-after.md と矛盾しているのですか（"may have failed" のような曖昧な表現が "failed" に書き換えられている）？
README の表（README.md:17-18）は、PR #4 が examples/before-after.md にモダリティ保持ルールを追加した際に更新されなかったため、両方の「After」セルがスキルが禁止しているアンチパターン（ヘッジを落とすと主張が変わる）をそのまま示しています。修正: 2つの「After」セルを examples/before-after.md の修正済みの書き換え文に置き換えてください。
行1 — ヘッジを保持する: Example A の「After」を使用: "The tool tries to synchronize state across the configured backends." "will attempt to" を "synchronizes" に書き換えないでください。また、"the tool resolves the conflict" ではなく "may resolve" を維持してください。
行2 — Example B の「After」を使用: "Your request may have failed. The cause may be a data format that does not match what the server expects. An outdated client can cause this mismatch. Check your client version." "The request failed... an outdated client is the most common cause" は使用しないでください — 前者はシステムが疑っているにすぎない失敗を断定しており、後者は入力に存在しない頻度に関する主張を捏造しています。
注: 矛盾する Before/After のペアは、存在しないよりも悪いです。両方のファイルを読むモデルは、その表を最も強いシグナルとして扱うためです。