plain -- 専門用語/コードの応答を平易な英語に翻訳する
このスキルが強制する基本ルール：チャット内で理解しやすく消化しやすい英語を維持すること -- 自己発明的なコードはすべて平易な言葉で説明し、プロセス説明の下に何も埋もれさせない。
このルールはしばしば破られてきた -- 応答にはファイルコード（F027、B13、PTT、def_hash...）、展開されていない略語、読み手にとって壁となる複合名詞の連なりが詰め込まれて返ってくる。このスキルはその修正策である：その応答を受け取り、平易で会話調の、余裕のある英語でもう一度言い直す。
これはアンチ簡潔スキル -- /breakdown（要約・短縮）の真逆です。長さは構いません；意味を失うことが問題なのです。
翻訳対象
デフォルトの対象：直前のアシスタントメッセージ。ユーザーがテキストを貼り付けたり、ファイル/ブロックを @ メンションした場合は、そちらを翻訳します。どちらか曖昧な場合は、一度だけ確認します。
やり方
- すべてのコード、タグ、略語を実際の意味に解決する -- 推測してはいけません。 ファイルコード、フェーズ名、ゲート名、ハッシュなどが出現したら、プロジェクトファイル（例：
findings.md、CHECKPOINT.md、該当する仕様書）でそれを調べ、実際に何であるかを人間の言葉で述べてください。もしコードの参照先を本当に見つけられない場合は、「Xが何を指すか見つけられませんでした」と言ってください -- 決して意味をでっち上げてはいけません。 - 要約ではなく言い換える。 すべての内容を保持する。これは翻訳であり、トリミングされた再録ではありません；短くするために詳細を落とすのが失敗モードです。
- 複合名詞の連なりや入れ子になった節を分解し、短くて普通の文にします。
- 新しい短縮形を導入しない -- コードやプロジェクト専門用語は使わない。どうしても避けられない専門用語は、最初に使う時にその場で定義してください。
- 読みやすい構造にする -- 長い段落ではなく、短い段落か簡潔なリストを使う。
ルール
- 平易で会話調の英語で、消化しやすいように構造化する：答えを最初に置き、短い段落で、すべての用語を定義するのに十分な広がりを持たせる -- 決してテキストの壁を作らない。
- 解決できなかったコードに対して意味をでっち上げてはいけない。
- 新しい分析、意見、次のステップを追加しない -- 既存の内容を読みやすくするだけ。ユーザーがさらに必要なら、尋ねてくるでしょう。