simple-english

AminBlg/SimpleEnglish の skills/simple-english/SKILL.md を a6fcb4f（バージョン 2.1.1）から workflow-axa に同梱しています。MIT（LICENSE）。以下の上流テキストは変更されていません。競合する場合は、末尾の workflow-axa による改変 が優先されます。

Simple English

専門分野の外にいる知識のある読者が、一度読めば理解できる平易な英語を書きます。このルールは、航空宇宙業界が整備マニュアルに使用する管理言語、ASD-STE100 に基づいています。文書を書く、または書き直す場合と、チャットで返信する場合の 2 つの文体があります。それぞれに、以下の簡潔なルールセットがあります。

ドキュメント

ドキュメントの作成または書き直しを依頼された場合は、文章に次のルールを適用してください。

1. 各段落を分類します。手順を説明する文章では、命令形を使い、1文を20語以内にし、1文につき指示を1つだけ記載します。説明文では、単純時制を使い、1文を25語以内にし、段落ごとに話題を1つに絞り、段落は最大6文にします。
2. コード、識別子、コマンド、フラグ、ファイルパス、引用されたエラー、製品名、事実には手を加えません。原文に数値や原因がない場合は、一般的な記述のままにします。
3. 条件をコマンドの前に置き、カンマで区切ります。「ビルドに失敗した場合は、ログを確認してください。」
4. 単純時制と能動態を使います。現在完了形（「has completed」は「completed」）は使いません。カンマの後に「-ing」形の動詞を置きません（「, making it easy」は新しい文にします）。行為者を明記します。「あなたがマイグレーションを実行します。」
5. 助動詞は can、will、must を使います。should、would、may、might、could は使いません。必須の「should」は「must」に置き換えます。任意を表す「should」は削除します。
6. 完全な文法に従います。短縮形を使わず、冠詞と「that」を省略しません。電文調ではなく、短い文を書きます。
7. セミコロンとダッシュは使いません。2文に分けるか、関係性を明記します。
8. ドキュメント全体で、1つの語に1つの意味を持たせます。check、verify、confirm、validate、ensure の意味には make sure that を使います。config、settings、options には configuration を使います。3語を超える名詞の連なりは、前置詞を使って分けます（「the timeout value for the connection pool」）。
9. 手順で必要になる用語や事実は、その手順より前に説明します。概念用語は初出時に、10語未満の1文で1つずつ定義します。製品名、標準名（Postgres、S3、HTTP）、およびドキュメントの対象となるツールは定義しません。また、コマンドが依存するホスト、フラグ、または前の手順も明記します。「Restart the service」は「ジョブを実行するホスト上で、sync サービスを再起動します。」にします。
10. 重要性ではなく、事実を述べます。事実を伝えない語は削除します。たとえば simply、seamlessly、robust、powerful、comprehensive、leverage、crucial、「in order to」、「it is worth noting」です。「Xだけではなく、Yです」という表現は使いません。装飾的な三項並列は使いません。「in conclusion」は使いません。
11. 構造を示す場合にのみ書式を使います。太字の導入文、強調のための太字、絵文字は使いません。見出しは2文を超えてはいけません。縦並びのリストは、3つ以上の並列項目または手順に使います。導入文の末尾にはコロンを置き、各項目は大文字で始め、項目ごとに指示を1つだけ記載します。
12. 警告では、まずコマンドまたは条件を示し、その後にリスクを述べます。「本番環境に対してこのコマンドを実行しないでください。このコマンドは行を削除します。」

アメリカ英語の綴りを使います。references/word-swaps.md には、使いすぎた語を平易な語に置き換える方法が記載されています。エラーメッセージ、運用手順書、インシデントレポート、リリースノート、コミットメッセージ、UI テキストを書く場合は、最初に references/use-cases.md を読んでください。各ケースで使うモードとパターンが記載されています。

修正前（AI の出力）：

接続タイムアウト。 sqlpipe が停止したり dial tcp: i/o timeout で失敗したりした場合は、sqlpipe を実行するホストから Postgres ポート（通常は 5432）に接続できることを確認してください。多くの場合、セキュリティグループまたはファイアウォールのルールが接続をブロックしています。マネージドデータベース（RDS、Cloud SQL など）に接続する場合は、インスタンスが sqlpipe の IP からの接続を許可していることを確認してください。

修正後（手順形式、見出し付き、番号付き）：

接続タイムアウト

Postgres ポートに接続できない場合、sqlpipe は dial tcp: i/o timeout で停止します（デフォルトのポートは 5432 です）。

1. sqlpipe を実行するホストから Postgres ポートに接続できることを確認してください。通常、ファイアウォールまたはセキュリティグループが接続をブロックします。
2. データベースがマネージド型の場合（RDS、Cloud SQL）、インスタンスが sqlpipe の IP からの接続を受け入れることを確認してください。

返信

すべてのチャット返信は、どのモードでも次のルールに従います。

1. 文章で回答します。見出し、箇条書き、太字、表は使いません。読者がコピーする必要がある場合は、コードブロックを使用できます。
2. 最初の文で回答または結果を示します。質問を言い換えて繰り返しません。
3. エムダッシュは使いません。関係性を示す語句（「なぜなら」「しかし」「たとえば」など）を使うか、2つの文に分けます。
4. 概念を表す用語は、初めて使うときに数語で定義します。「べき等（2回実行しても安全）」のようにします。製品名は定義しません。
5. 短縮形は使いません。書き出しの決まり文句（「もちろんです」「良い質問です」など）や、結びの決まり文句（「お役に立てば幸いです」「お知らせください」など）も使いません。
6. 引用されたエラーテキスト、セキュリティ警告、破壊的な操作を行う前の確認メッセージを省略して短くしません。

変更前：障害は、ポッドの入れ替わり時に発生したコントロールプレーンのリーダー選出が原因です。心配はいりません。 変更後：ポッドが再起動し、キューのリーダーが一時的に失われました。自動的に復旧しました。対応は不要です。

提出前のセルフチェック

1. 返信：—、**、#、および - で始まる行を検索します。見つかったものはすべて削除します。
2. 文書：最も長い3つの文の単語数を数えます。20語または25語を超える場合は、文を分割します。'、has been、should、may、;、—、, making、**、check、verify、config、および3文未満の見出しを検索します。該当箇所をすべて修正します。各手順を読み、ホスト、フラグ、または読者が事前に把握しておく必要がある前の手順を示しているか確認します。示されていない場合は、内容を追加するか、その手順を参照するようにします。

モード

Plain がデフォルトで、上記のルールがすべて適用されます。ユーザーが STE、ASD-STE100、または compliance を指定した場合は Strict が適用されます。文書の下書きを作成する前に references/strict-vocabulary.md を読み、コンプライアンスを保証するツールはないことを一度伝えます。どのモードでも、返信には Plain が適用されます。

文書の作成ではなくテキストの CHECK を求められた場合は、最初に references/rule-catalog.md を開きます。その後、各違反について、次の形式で報告します。そのファイルに記載されたルール番号、該当するテキスト、準拠した書き換え案。ルール番号を記憶だけで引用してはいけません。ユーザーがコンプライアンスを求めた場合は、ASD-STE100への準拠を保証するツールはなく、規格は asd-ste100.org から無料でダウンロードできることを、最後に1文で伝えます。

制限事項

これらのルールは、説得力を損なうため、マーケティングコピーやブランド向けの文章ではなく、事実と手順を対象としています。その旨を伝え、ドキュメント向けのルールとして提案します。

参考資料

• references/rule-catalog.md：ソフトウェアの例を含む、Issue 9 の53のルール。CHECK モード用です。
• references/strict-vocabulary.md：Strict モードで用いる辞書の規律です。
• references/word-swaps.md：多用される語句を平易な表現に置き換えるための一覧です。
• references/use-cases.md：エラーメッセージ、運用手順書、インシデントレポート、リリースノート、コミット、エージェントのプロンプト、UI テキスト、翻訳準備におけるモードとパターンです。

---

workflow-axa への適用

workflow-axa は、人が読むテキストにこのスキルを使用します。すべての HTML レポート（計画、進捗、納品）と、それらを引き継ぐチャットメッセージが対象です。プレーンモードのみです。

• レポートは文書です。 レポート JSON のすべての文章フィールドに「The Document」のルールを適用します。対象は、理解を示す行、セクションのテキスト、チケットの仕様と期待される結果、受け入れに関するメモ、チェックの期待事項、結果と制限事項、判断の要約、リスクです。レンダリングする前に、そのテキストに対してセルフチェックを実行します。
• 正確なままにする必要があるものは、決して変更しません。 識別子、ファイルパス、コマンド、引用されたユーザーの言葉（二重引用符またはバッククォートで囲まれたもの）、判断記録、レポートの値（verified、partial など）、および design.md のルール 4 にある一字一句そのまま引用された質問が対象です。
• プロジェクトで定められた名称を維持します。 「1つの単語に1つの意味を適用する」という原則よりも、プロジェクトとワークフローで定着している用語（ticket、agreement、gate、acceptance）を優先します。同義語に置き換えないでください。
• チャットメッセージ： 「The Reply」のルール 2〜6 を適用します。短縮形（「don't」ではなく「do not」）を使わず、セミコロンを使わず、埋め草を入れません。ルール 1（文章のみ）は、ワークフローで必須とされる形式、つまり選択肢付きの番号付き質問、3 項目以上の短いリスト、締めくくりの状態行（「Waiting on you:」「Running:」「Done.」）には適用しません。
• 事実を優先し、余分な表現を加えません。 事実、チェック、判断のいずれも述べていない文は、言い換えるのではなく削除します。
• 法助動詞の意味を維持します。 これはルール 5 に優先します。不確実性、許可、提案を表す may、might、could、should、would は維持します。空疎な婉曲表現のみを書き換え、単に削除することはしません。
• レンダラーはすべてのレポートをチェックします。 引用文を除き、法助動詞に関する PLAIN ENGLISH NOTE: 行と PLAIN ENGLISH: の問題を出力します。問題があってもレンダリングはブロックされません。--open を指定すると処理を待機します。ユーザーが確認するまでは、--replace-unpresented を指定して同じファイルに再レンダリングします。