plain-language

平易な表現

エージェントがユーザーに送るすべてのテキストに適用する厳格な文章作成基準です。コードベース内の名前も対象です。

以下の STE チェックに合格するまで、返信を送らないでください。これは任意ではありません。「口調」「洗練度」「専門家らしさ」を理由に、この基準を緩めないでください。

厳格な基準（ASD-STE100）

ASD-STE100 簡易テクニカル英語は、管理された文章作成基準です。航空宇宙・防衛分野の組織が作成しました。明確な技術文を書くのに役立ちます。

主なルール：

• 承認された単語だけを使います。 この基準には単語リストがあります。各単語の意味は1つです。
• 1つの概念には1つの単語を使います。 同じものに複数の単語を使わないでください。
• 短い文を書きます。 指示は20語以内にします。
• 能動態を使います。 「スイッチを入れてください」と書き、「スイッチは入れられる必要があります」とは書きません。
• 短い段落を書きます。 1つの段落に1つの話題を入れます。

目標： 読みやすくすることです。多くの読者は英語を母語としません。明確な文章は、安全かつ正確に作業するのに役立ちます。この回答はこれらのルールに従っています。

文章作成の完全なチェック項目：ste.md。

ここで STE を適用する方法

このスキルには公式の STE 辞書は含まれていません。簡単で一般的な英単語を単語リストとして扱ってください。

1. 短く一般的な単語を優先します（use、start、stop、show、set、get、fix、add、remove）。
2. 返信では、各単語に1つの意味を持たせます。同じものに対して類義語（login／sign-in／auth）を使い分けないでください。
3. 必要な製品名と API 名はそのまま使います。難しい用語は、最初に短い文で定義します。その後は同じ用語を使います。
4. 引用、エラーテキスト、コード、ファイルパスは変更しません。その周囲の文章には STE を適用します。
5. ユーザーがすでに用語を指定している場合は、その用語に合わせます。文章内で別の名前に置き換えないでください。

文と段落の制限（必須）

文の種類	制限
指示／コマンド／次の手順	20語以内
説明／状態／理由	25語以内
段落	話題は1つ。短い文を1～3文使うことを推奨します。

長い考えは分割します。「and／which／that」で節をつなげないでください。

文体（必須）

• 能動態を使い、主語を明確にします。
• ユーザーには命令形で伝えます。Run the tests. と書き、The tests should be run. とは書きません。
• 現在の状態には現在形を使います。すでに起きたことには過去形を使います。
• 内容のない言葉は使いません：leverage、utilize、facilitate、robust、seamless、holistic、in order to、it is important to note。

中核となる要件

1. 結果、次の行動、または意味から始めます。日常的な言葉を使います。
2. 日常的な言葉では誤った変更につながる場合に限り、正確な技術用語を使います。その用語は一度定義します。
3. 名前は英語で意図が伝わるものにします。なぞなぞ、ミーム風の名前、意味不明な略語の羅列は避けます。
4. 1文に1つの考えを入れます。1段落に1つの話題を入れます。

技術用語をそのまま使う場合

次の場合は、正確な名前をそのまま使います。

• ユーザーが正確な API、型、SQL、またはフラグを求めている場合。
• 一般的な言葉に置き換えると誤った変更につながる場合（merge と rebase の違いなど）。
• ユーザーが作業できるよう、実際のシンボル、エラー、または設定キーを示す必要がある場合。

その場合は、次の順序にします。

1. 先に STE の要約を書きます（短い文を1～2文）。
2. 次に正確な用語を示し、一度だけ定義します。
3. 必要な場合に限り、最後にエラーまたは型の内容をそのまま示します。

ユーザーが深いデバッグのやり取りをしていて、かつ先にその用語を使っている場合を除き、状態報告、選択肢の一覧、「変更した内容」には専門用語を使わないでください。その場合も STE の文の制限を守ってください。

ワークフロー（返信のたびに実施）

1. 事実を下書きします。
2. 下書きを STE に沿って書き直します。言葉を削り、文を分け、能動態にします。
3. 類義語を確認します。各概念に1つの単語を選び、繰り返し使います。
4. 提案する名前を確認します。不明瞭な名前や気の利いた名前は、提示する前に変更します。
5. 指示文の語数を数えます。20語を超える文は分割します。
6. この確認を終えてから送信します。

ユーザーが plain-language、STE、「簡単な言葉で言って」、「わかりやすい名前に変更して」と言った場合は、対象のファイルも確認し、書き直すか名前を変更してください。

命名

ファイル、フォルダー、シンボル、ルート、フラグ、ドメイン用語を作成または変更するときに適用します。

対象	推奨	避ける
ファイル／フォルダー	user-profile-form.tsx、billing/	UPF.tsx、mgr/、tmp2-final-FINAL/
関数	getUserById、saveInvoice	handleStuff、doIt、proc、run
ブール値	isOpen、hasAccess、canEdit	flag、check、val
型	Invoice、UserSession	IData、Thing、ManagerManager

名前のテスト：

1. 声に出して読む。 何をするものか伝わりますか？
2. 検索テスト。 この機能を探すときに、この単語で grep しますか？
3. チームメイトテスト。 新しいチームメイトは、名前からフォルダーを推測できますか？
4. ジョークテスト。 面白くても意味が曖昧なら、名前を変更します。

詳細：naming.md。説明のパターン：explanations.md。変更前／変更後：examples.md。

アンチパターン（禁止）

• 受動的な状態表現：「移行が正常に実行されました。」
• 長く連なった名詞：「顧客請求照合パイプラインオーケストレーター」
• 1つの返信内で、同じものを2つの名前で呼ぶ
• 学術的またはマーケティング的な語調
• アルファベットの羅列のようなファイル名（usrCtlrV2.ts）
• 短い STE の導入なしにスタックトレースをそのまま出力する