unsloppify

unsloppify

スロップとは、情報を伝えるのではなく、見せかけの効果を狙う文章です。飾り立てても解決にはなりません。 飾らない表現で述べてください。これは、書き手が人であれモデルであれ、あらゆる草稿に当てはまります。 誰が書いたかではなく、文章そのものを評価してください。

読み込むタイミング

成果物のすべて、または大部分がテキストである場合に、このスキルを読み込んでください。たとえば、文書、PR やコミットのテキスト、リリースノート、レポート、マーケティング文、まとまった量のコードコメントなどです。ほかの作業に付随して生成される文章は該当しません。チャットの返信、状況報告、ツールの解説、完了サマリーなどです。これらには基本の文章ルールが適用されます。スキルを読み込んだものの、タスクが該当しない場合は、手順を省略してタスクを続けてください。

手順

機械的なハウスルール（ダッシュ、セミコロン、UTF の中黒を見つけ次第削除すること）を除き、以下の各項目は、その形式が本当に必要か、ほかの飾らない表現では言い換えられない特定の状況にぴったりの言葉なのかを確認するためのきっかけです。理由がある場合に限り、その形式を使ってください。目標は、定型表現を見つけて書き直すことであり、草稿が何も言えなくなるほど臆病になることではありません。

草稿の作成：

1. 文脈（散文、ドキュメント、PR やコミットのテキスト、コードコメント、学術文書）を特定します。執筆中は、以下にあるその文脈のルールを適用してください。二次的な文脈は最大 1 つだけ読み込んでください。
2. 最終テキストを出力する直前に、6 つの失敗モードを読み直してください。長い作業の早い段階で読んだルールは薄れてしまいます。この手順はそのためにあります。
3. 6 つのテストに照らして自分で確認します。1 つの例は許容される場合があります。繰り返しや集中して現れることが問題です。
4. 草稿内で、単語間のハイフンを一通り確認します。複合修飾語はすべて、読者に定着した用語か、文字どおりのコード識別子でなければなりません。それ以外は、飾らない言葉で言い換えてください。これはよく見られる兆候なので、独立した確認項目に値します。

既存文書の監査：

1. 文書に対して scripts/scan.sh（または rg -i -f references/phrases.txt）を実行します。これにより、文字どおりの兆候を推論の手間なく見つけられます。スキャナーが検出するのは、フレーズ単位の兆候だけです。バナーコメント、価値の反復、太字を先頭に置く書式など、構造上の兆候は自分で読み取る必要があります。リストの末尾には、要確認のグループ（bare cannot、never、gate、actually、land、ship、sits、矢印、否定の付け足し、ハイフン付き複合語）があります。該当箇所の多くは妥当です。各箇所について確認すべき点であり、報告すべき問題ではありません。
2. 文書の構造を一度読みます。見出し、書き出し、結びを確認し、繰り返される形、比喩、テンプレート的な展開があれば指摘します。
3. テキストをセクションごとに読みます。セクションごとに 6 つのテストを適用してください。長い文書は複数回確認します。
4. 書き直す前に、すべての候補を指摘事項リスト（場所、引用、モード）にまとめます。
5. リストに沿って書き直します。その後、全体を一度読み、文体、事実、一貫性を確認します。詳細な監査では references/patterns.md を読み込んでください。

ガード

ルールが衝突する場合の優先順位：事実上の意味、引用された内容、ユーザーが求める文体、分野の文体、反スロップルールの順です。

• 書き直しをしても、事実はすべて維持します。数値、名前、日付、URL、引用、単位、コード識別子、対象範囲を示す言葉、否定表現などです。
• 内容を持つ留保表現は残してください（法律、医療、セキュリティ、学術）。
• 反スロップ調に過剰に修正しないでください。歯切れのよい言い切りで終える表現、「X ではなく、Y。」という断片、無理にぶっきらぼうにする表現も、兆候です。
• 議論の対象になっているスロップ表現は、引用されたまま残してください。

6 つの失敗モード

1. 重要性の誇張

傾向：モデルは権威があるように聞こえる表現を補いがちで、そのため、説明された重要度の代わりに断言の強さで重みを示します。 確認方法：評価を表す語を削除します。意味が変わらなければ、その語は飾りです。 禁止表現：crucial、essential、vital、paramount、transformative、cannot be overstated、more important than ever、plays a key role、stands as a testament、paving the way、単に「not」と述べれば事実が伝わる箇所での大げさな断定（cannot、never、always）。例外：同じ文の中で明示する依存関係、文字どおり不可能なこと。 例：「キャッシュはシステム全体のパフォーマンスにおいて重要な役割を果たします。」→「キャッシュにより読み取りレイテンシーが40％低下します。」 推測の目安：説明するのではなく、対象を評価する言葉はすべて該当します。

2. 作り出されたドラマ

傾向：モデルは説得力のある文章のリズムを借りるため、実際には存在しない緊張感を演出しがちです。 確認方法：文の内容では解消されない期待感をあおっていませんか。または、代替案を否定する形で事実を述べていませんか。 禁止表現：「単なるXではなく、Yです」、「Xはありません。Yもありません。Zだけです。」、「注意点は？」、自問自答の質問、一行だけの決めぜりふ、「実のところ」、「よく考えてみてください」、肯定文で事実を述べられる箇所での否定の付け足し（「、Xではありません。」「、Xもありません。」）。例外：肯定文だけでは誤解の余地が残る場合に、それを防ぐ対比（「リクエストごとではなく、ホストごと」）。 例：「これはキャッシュではありません。まったく新しいアーキテクチャです。」→「この変更でキャッシュが追加されます。」 推測の目安：事実が裏付けていないのに、意外な事実を明かすかのような表現はすべて該当します。

3. 気取った文体

傾向：モデルは専門知識を示そうとして、格調高い語彙や業界用語を選びがちです。 確認方法：平易な動詞で同じことを表せるなら、そちらを使います。 禁止表現：delve、tapestry、seamless、leverage、robust、utilize、facilitate、serves as、functions as、footgun、blast radius、battle-tested、「review-shaped output」や「genuine-need escape hatch」のように、平易な言葉で表せる即席のハイフン付き複合語。例外：文字どおりの正確な意味で使う用語、または読み手にも定着している複合語（thread-local、copy-on-write）。各複合語を個別に使うのは問題なくても、1つの段落で複数使うのは避けます。 例：「バリデーターは、不正な入力に対する門番として機能します。」→「バリデーターは不正な入力を拒否します。」 推測の目安：意味より響きを優先して選ばれた言葉はすべて該当します。

4. 見せかけの精密さ

傾向：モデルは情報の欠落を、確信ありげな診断名や大まかな出典で埋めがちです。 確認方法：仕組み、出典、または数値を具体的に示します。示せない場合は、その主張を削除します。 禁止表現：仕組みを明示しない診断名（race condition、deadlock、memory leak）、「研究によると」、「XからYまであらゆるもの」、でっち上げた概念名。 例：「クラッシュの原因はおそらく競合状態です。」→「長さの更新後、ペイロードの書き込み前に、読み取りスレッドがバッファーを参照する可能性があります。」 推測の目安：具体的に聞こえても、検証可能な内容を示していない主張はすべて該当します。

5. テンプレートの穴埋め

傾向：モデルはよくある論説の型をなぞるため、書き出しや締めくくりを反射的に付け加えます。 確認方法：その文に内容がありますか。それとも形式上必要な枠を埋めているだけですか。 禁止表現：「結論として」、「変化の速い現代社会において」、まとめの見出し、反射的な三項列挙、太字のラベルから始まる箇条書き。 例：「パフォーマンス：新しいインデックスにより検索が高速化します。」→「検索は新しいインデックスを使うようになり、5ミリ秒未満で結果を返します。」 推測の目安：内容上必要だからではなく、テンプレートに含まれているから追加された要素はすべて該当します。

6. 制作過程の混入

傾向：モデルはチャット調の表現、レビュー履歴、相互参照など、制作過程の痕跡を成果物に残しがちです。 確認方法：文書が最初から完成した状態だったとしても、このテキストは存在しますか。 禁止表現：「レビューのフィードバックを受けて」、「上記のとおり」、「お役に立てば幸いです」、「今回、…にも対応しました」、コードコメントに残る会話の残骸。 例：「// レビューフィードバックを受けて、空の配列にも対応」→「// 空の配列の場合は0を返す」 推測の目安：内容ではなく、テキストが作られた経緯を示す痕跡はすべて該当します。

文脈に応じたルール

文章：

• 前置きではなく、具体的な事実から始めます。
• 文の長さに変化をつけます。三つ並べる表現や、反射的に繰り返す文頭表現には注意します。
• 程度を評価するだけで、測定にはならない副詞を削ります。
• 一つの考えにつき比喩は一つにとどめ、使い古された比喩は取り除きます。
• 結びを読み返します。内容を言い直しているだけなら、最後の要点で終えます。

ドキュメント：

• 対象の機能、または実行方法から書き始めます。
• 「X を実行できます」ではなく、「X を実行します」のように命令形を使います。
• どの機能にも、根拠のない利点を付け加えません。
• 説明を三文並べるより、具体的な使用例を一つ示します。
• 見出しには内容を示す言葉を使い、「概要」のような中身のない見出しは避けます。

PR とコミットメッセージ：

• 件名だけで変更内容が伝わるようにします。計画を知らない人にも読める表現にします。
• 計画上のラベル、段階番号、このセッションでしか解釈できない参照は使いません。
• 大げさなエンジニアリング用語は避け、実際の仕組みを明記します。
• 件名だけで理由が伝わらない場合に限り、本文を追加します。

コードコメント（まず必要性を確認）：

• コメントには、コードだけでは分からないことを書きます。コードから分かる内容なら、コメントを削除します。
• バナーや区切りのコメントは使いません。内容が明らかな行の上にラベルコメントを置きません。
• リテラルの値を横に書き直しません。
• コメントにレビューの履歴や会話の残りを持ち込みません。
• しないことではなく、コードが何をするかを記述します。「X ではなく」や「X もない」という補足は、読者が実際に誤解しそうな場合にだけ残します。
• 節を正しい接続詞でつなぎます。節と節の間に単にコンマを置くと、「そして」「だから」「しかし」の関係が隠れてしまいます。接続詞を書くか、文を分けます。

学術文書：

• 実際の不確実性を表す留保は残します。単に表現を和らげるだけの留保は削ります。
• 「研究によると」ではなく、具体的な研究、サンプル、知見を示します。
• 難しい語彙より平易な表現を優先します。主張を直接述べます。
• 新たに作った用語は、初出時に平易な言葉で定義します。

過剰使用のルール

パターンは、機械的なハウスルールを除けば、一度だけなら問題ない場合があります。 複数のパターンが重なること、または同じパターンを繰り返すことが失敗につながります。 変化に富み、具体的で、平易な文章を書きます。