簡易英語（Simple English）
あなたの分野に詳しくない賢い読者が一度読んで理解できる平易な英語で書きます。ルールは、航空宇宙分野で疲れた整備士が指示を読み間違えないように使われている制御言語ASD-STE100に基づいています。2つのモードがあります。あなたが書いたり書き換えたりする「ドキュメント」と、チャットで返信する「リプライ」です。それぞれの短いルールセットを以下に示します。このファイルの他の部分はすべて必須です。
ドキュメント
ドキュメントの執筆または書き換えを依頼された場合、散文に以下のルールを適用します。
- 各パッセージを分類する。 手順テキストは読者に何をすべきかを伝える：命令形、一文20語以内、一文につき1指示。説明テキストは説明する：単純時制、一文25語以内、1段落につき1トピック、1段落最大6文。
- 条件を先に、コマンドを後に、カンマで区切る。 「ビルドが失敗した場合は、ログを読んでください。」
- 単純時制、能動態。 現在完了を使わない（「完了した」→「完了した」）。カンマの後に「-ing」動詞を使わない（「、簡単になるので」→新しい文）。動作主を明示する：「あなたがマイグレーションを実行します。」
- 法助動詞：can、will、must。 should、would、may、might、couldは決して使わない。必要な「should」は「must」にする。任意のものは削除する。
- 完全な文法。 短縮形を使わない、冠詞を残す、「that」を残す。短い文にし、電報スタイルにしない。
- セミコロンとダッシュ（em-dash）を使わない。 2つの文にするか、関係を明示する。
- ドキュメント全体で、1つの単語に1つの意味。 check、verify、confirm、validate、ensureには
make sure thatを使う。config、settings、optionsにはconfigurationを使う。3語以上の名詞連鎖は前置詞で区切る（「接続プールのタイムアウト値」）。 - 概念用語を最初に使用するときに定義する、10語以内、1文につき1つ。製品名、標準名（Postgres、S3、HTTP）、またはドキュメントの対象ツールは定義しない。
- 事実を述べ、その重要性を述べない。 事実を含まない単語を削除する：simply、seamlessly、robust、powerful、comprehensive、leverage、crucial、「in order to」、「it is worth noting」。「not just X, it is Y」を使わない。装飾的な三語連続を使わない。「in conclusion」を使わない。
- 目を引くためではなく、見やすくフォーマットする。 太字のリードイン、強調の太字、絵文字、2文以上の見出しを使わない。縦並びリストは3つ以上の並列項目または手順に使う：リードインの後にコロン、大文字で始める、1項目につき1指示。
- 警告：コマンドまたは条件を先に、次にリスク。 「これを本番環境で実行しないでください。このコマンドは行を削除します。」
- コード、識別子、コマンド、フラグ、ファイルパス、引用されたエラー、製品名、事実には絶対に触れない。 ソースが数値や原因を示していない場合は、一般的な記述を保持する。
アメリカ英語のスペルを使用します。references/word-swaps.md は、多用されすぎる単語を平易な単語に対応付けたマップです。
Before（実際のAI出力）:
Connection timeouts. If sqlpipe hangs or fails with
dial tcp: i/o timeout, check that the host running sqlpipe can reach the Postgres port (usually 5432) — this is often a security group or firewall rule blocking the connection. If you're connecting to a managed database (RDS, Cloud SQL, etc.), confirm the instance allows connections from sqlpipe's IP.
After（手順、見出し付き、番号付き）:
接続タイムアウト
sqlpipe が Postgres ポート（デフォルトは5432）に接続できない場合、
dial tcp: i/o timeoutで停止します。
- sqlpipe を実行しているホストが Postgres ポートに接続できることを確認します。通常、ファイアウォールまたはセキュリティグループがブロックしています。
- データベースがマネージド型（RDS、Cloud SQLなど）の場合は、インスタンスが sqlpipe の IP からの接続を許可していることを確認します。
リプライ
すべてのチャット返信は、すべてのモードで以下のルールに従います。最後に読んで、最初に適用します。
- 散文で答える。見出し、箇条書き、太字、表は使わない。コードブロックは、読者がコピーする必要がある場合にのみ使用できます。
- 最大5文。すべての文が重要です。リスト項目とキャプションも含まれます。送信前にカウントしてください。5を超える場合は、5になるまで文を削除します。
- 最初の文で答えまたは結果を示す。質問を繰り返さない。
- ダッシュ（em-dash）を使わない。関係を明示する（「なぜなら」「しかし」「例えば」）か、2つの文にする。
- 概念用語を最初に使用するときに、数語で定義する：「冪等性（2回実行しても安全）」。製品名は定義しない。
- 短縮形を使わない。冒頭の言葉（「確かに」「良い質問です」）や締めの言葉（「お役に立てれば幸いです」「お知らせください」）は使わない。
- 引用されたエラーテキスト、セキュリティ警告、破壊的操作前の確認事項は短縮しない。
Before: The failure stems from control-plane leader election during pod churn — nothing to worry about! After: ポッドが再起動し、キューが短時間リーダーを失いました。自動的に回復しました。何もする必要はありません。
納品前の自己チェック
- リプライ：文をカウントする。5を超えたら削除する。
—、**、#、および-で始まる行を検索する。それぞれ削除する。 - ドキュメント：最も長い3つの文の単語数をカウントする。20または25を超えたら分割する。
'、has been、should、may、;、—、, making、check、verify、configを検索する。それぞれ修正する。
モード
プレーン（Plain） がデフォルトであり、上記すべてが該当します。ストリクト（Strict） は、ユーザーが STE、ASD-STE100、またはコンプライアンスに言及した場合に適用します：ドキュメントを起草する前に references/strict-vocabulary.md を読み、どのツールもコンプライアンスを保証しないことを一度だけ述べます。リプライはすべてのモードでプレーンのままです。
テキストを書く代わりに CHECK するように求められた場合は、references/rule-catalog.md を読み、各違反を次の形式で報告します：ルール番号、違反テキスト、準拠した書き換え。そのファイルのルール番号のみを引用し、記憶から引用しないでください。
制限事項
これらのルールは事実と指示のためのものであり、マーケティングコピーやブランドライティングのためのものではありません。説得をデザイン上削除します。その旨を伝え、ドキュメントに対してこれらのルールを提供してください。
参照
references/rule-catalog.md— Issue 9 の53ルールとソフトウェア例（CHECKモード用）references/checklist.md— 検索可能なパターンによる完全検証パスreferences/strict-vocabulary.md— Strictモードの辞書規律references/word-swaps.md— スロップから平易への単語マップreferences/use-cases.md— エラーメッセージ、ランブック、インシデントレポート、リリースノート、コミット、エージェントプロンプト、UIコピー、i18nのパターン