no-slop

余計な飾りをなくして書く

文体

目指す文体：英語をC2レベルで書くドイツ人の専門職。正確で、直接的で、構成が明快。熱意を前面に出さず、落ち着いた調子です。これは文体の話であり、訛りの話ではありません。ドイツ語的な表現、誤用を招きやすい語、文法の誤りは避けます。ほぼネイティブ並みの英語ですが、陽気さを基本とするアメリカ英語の定型には寄せません。

AI が生成する冗長な文章の大半は、間違っているのではなく、書き込みすぎで、構成を整えすぎています。温かすぎる、両論併記しすぎる、足場を組みすぎる、自分で要約したがりすぎる。そうした要素を削れば、文章は短く、良くなります。目標は、意図を持って書かれた、力量のある人の文章です。

上位から順に進める

冗長さは目次から単語に至るまで、あらゆる規模で生じます。構成そのものが冗長な文章の文を磨いても、労力の無駄です。そこで、各パスを順番に進めます。各パスでは、後のパスで磨くことになる文章を先に削除します。

1. 文書を考え直します。 セクション全体を並べ替え、統合し、分割し、削除し、置き換えます。手順は以下に、具体例は structure.md にあります。
2. 段落を組み直します。 1段落につき1つのトピックとし、要点を先に述べ、手順は散文から切り離します。
3. STE の構文ルールに従って、文を適切に組み立てます。
4. 採用した Microsoft の表記ルールも含め、単語レベルの癖を取り除きます。
5. リンターで確認し、その後、人にしかできない読み直しを行います。

数段落を超える草稿で、言い回しだけを直したなら、最も重要なパスを飛ばしたことになります。構造を変更するか、構造が妥当である理由を述べてください。新しい文章を書く場合も、同じ順序で考えます。読者に必要なものは何か、どの順で伝えるか、段落をどう構成するか、そして文をどう組み立てるか。コード内（コメント、コミットメッセージ、テスト名、エラー文字列）を書く場合も、同じ文体を適用し、「散文以外」の該当ファイルを確認します。

常に守るルールが2つあります。周囲の文書に合わせてください（リポジトリの履歴、文書で定着している文体、指定されたテンプレートなど）。このルールは文章を磨くためのものであり、ユーザーが従うハウススタイルに優先するものではありません。また、他人の草稿を再構成する場合は、変更内容（「X を Y に統合し、Z を削除」など）を報告し、黙って変更しないでください。

パス1、文書を再構成する

見つけるもの	対応
内容を予告する導入、内容を振り返る結論、別のセクションを言い換えるセクション	削除するか、実質的な一文だけを本文に統合します
自動生成されたひな形（概要、機能、結論；2行の PR に対する概要、変更内容、テスト）	この文書に本当に必要なセクションに置き換えます。多くの場合、セクションは不要です
背景説明に埋もれた要点	並べ替え、読者が知りたいことを最初に示します
同じトピックを扱う2つのセクション	統合します
2つの役割を担う1つのセクション	分割します
論理的な説明が必要なのに、箇条書きが延々と続く箇所	散文に書き換えます
説明的な段落に埋もれた手順	番号付きリストに移し、1項目につき1つの操作を記します
2文ごとにある見出し	より少ない見出しの下にまとめます
内容に対して文書が2倍の長さになっている	短くします。半分の長さになるのはよくあることです

パス2、段落を組み直す

1段落につき1つのトピックとし、最大6文に収めます。最初の文で要点を述べます。リストを使うのは、項目が実際に並列かつ独立している場合に限ります（手順、選択肢、基準など）。考えがつながっている場合や、文脈が必要な場合は段落にします。実際の一連の操作にはリストが必須です。番号付きにし、命令形で、1項目につき1つの操作を記します。

パス 3、文を正しく組み立てる

このシステムは ASD-STE100 簡易テクニカル英語です。航空宇宙業界が 1986 年に、英語を母語としない読者にも理解できる保守マニュアルのために標準化しました。効果があります。禁止語リストだけを与えた場合、Claude が測定された冗長表現を 3% 削減したのに対し、このシステムを与えた場合は 74% 削減しました。ルール、モード、根拠の詳細は ste.md を参照してください。

ルール	このように書く	こう書かない
1 つのものには 1 つの名称を使う	キャッシュ、その後もキャッシュ	キャッシュ、その後はストア、その後はレイヤー
1 つの単語に 1 つの意味を持たせる	「fall」は下に動くことを意味する	減少を表すために「traffic fell」とする
短く一般的な単語を使う	使う、開始する、助ける、確認する、前、後、～について、得る、表示する、また	活用する、着手する、促進する、確実にする、～に先立って、～に続いて、～に関して、取得する、実証する、さらに
行為者を明示した能動態を使う	パーサーがファイルを読み取る	ファイルが読み取られる
1 つの動作に 1 つの動詞を使う	ログを分析する	ログの分析を実行する
助動詞を重ねない	これによりスループットが向上する	これによりスループットが向上する可能性がある
進行形より単純時制を使う	ジョブがインデックスを書き込む	ジョブがインデックスを書き込んでいる
句動詞より平易な動詞を使う	開始する、連絡する、読む、デプロイする	起動する、連絡を取る、詳しく調べる、公開する
1 文に 1 つの考えを入れ、長さに上限を設ける	指示は 20 語、説明は 25 語	40 語の連続した文
セミコロンを使わない	2 つの文	つなぎ合わせた 1 つの文
命令の前に条件を書く	キャッシュが空なら、先にウォームアップする	キャッシュが空なら、先にウォームアップする

パス 4、要注意表現（見つけたら削除）

要注意表現	修正方法
強調や補足に使うダッシュ	ピリオド、コンマ、コロン、または丸括弧に置き換えます
「XではなくY」／「単にXではなく、Yです」	Yをそのまま述べます
重要性のない三つ並べ（「高速、シンプル、信頼性が高い」など）	核となる一語だけ残します
前置きだけの書き出し（「今日の世界では」「〜に関して言えば」）	削除し、要点から始めます
本文を繰り返すまとめ（「結論として」「最終的には」）	削除するか、最後の要点で締めます
つなぎの水増し表現（「さらに」「そのうえ」「注目すべき点は」）	削除します。次の文はそのまま意味が通ります
無理に数を提示する表現（「理由は3つあります」など）、または切りのよい数に合わせて水増ししたリスト	要点を文章で述べ、本当に必要な項目だけ残します
反射的な曖昧表現（「〜に注意することが重要です」「おそらく」「〜する可能性がある」）	削るか、具体的で実質のある条件を明示します
お世辞や肯定（「良い質問です」「まさにそのとおりです」）	質問に答えます
無意味な大げさ表現（掘り下げる、活用する、乗り越える、領域、全体像、織物、複雑な、堅牢な、シームレスな、重要な、不可欠な、促進する、利用する）	平易な言葉に置き換えます
具体名があるのに使わないカテゴリ名詞（「該当するコンポーネント」）	実体を示します（「認証ミドルウェア」）
順序のない項目に番号を振る	番号は順序や順位を示すため、箇条書きにします
存在表現から始める書き出し（「選択肢は3つあります」）	主語を先に置きます（「選択肢が3つあります」）
読者を主語にする書き出し（「ファイルはオンラインに保存できます」）	動詞から始めます（「ファイルをオンラインに保存します」）
内容のない「〜できます」（「設定で再試行の上限を設定できます」）	削除します（「設定で再試行の上限を設定します」）
内容のないリンクテキスト（「ここをクリック」）、または方向だけを示す参照（「上記」「左側」）	リンク先を説明し、対象の名前を示します
重要性の誇張（「〜の証しとなる」「重大な節目となる」）	重要性の主張を削り、事実を述べます
誇張したコピュラ（「誇る」「役割を果たす」「備える」など、「〜である」「持つ」で足りる場合）	平易な動詞に戻します
出典が曖昧な権威付け（「研究によると」「専門家の見解では」）	出典を明記するか、主張を削除します
分詞句を連ねて文末に付け足す表現（「……その伝統をさらに確かなものにしています」）	事実を述べたところで文を終えます
見せかけの対象包括（「初心者でも専門家でも」）	実際の対象者を述べます
チャットボット的な前後置き（「詳しく見ていきましょう」「ご覧のとおり」「コーディングを楽しんでください」）	削除し、内容から始めて内容で終えます
否定形であおる表現（「Xに別れを告げましょう」「Yの時代は終わりました」）	その機能を述べます

動詞から始める書き方と、内容のない「〜できます」を避けるルールは、存在表現から始める書き方と同様に、Microsoft Writing Style Guideに由来します。これらのルールはすべてのモードで適用され、独自のスタイルルールではありません。シリアルコンマと見出しのルールを含む全体については、microsoft-style.mdとformatting.mdを参照してください。

曖昧な表現を削るときは、控えめな形容詞ではなく事実に置き換えます。曖昧な書き換えは、表現を弱めただけの同じ水増しです。リストにある言葉を、さらに回りくどい表現に置き換えてごまかさず、文全体を書き換えてください。

モード

Strictは、手順書、運用手順書、インストールや移行の手順、エラーやログのメッセージ、非推奨の告知に使います。STEルールをすべて適用し、文は20語以内にし、短縮形は展開します。Flavoredは、それ以外でのデフォルトです。文、動詞、段落に関するルールを守り、文は25語以内にします。短縮形と文体は維持します。House-styleは、Microsoftガイドのように、対象となる文書に確立したスタイルがある場合に使います。短縮形、ダッシュ、親しみやすさについては対象のスタイルを優先します。それ以外の要注意表現と、これまでのすべてのパスのルールは引き続き適用します。技術文書だからという理由ではなく、対象のスタイルに合わせて選んでください。

パス 5：ドラフトを確認する

上記の各パスに照らして一度読み直します。次に、リンターを実行します（この SKILL.md と同じ場所にある slop-lint.mjs を解決します）。

node slop-lint.mjs README.md              # a file, flavored mode
node slop-lint.mjs --strict runbook.md    # procedures, 20-word cap
echo "$draft" | node slop-lint.mjs        # prose not yet written to a file

編集の前後にリンターを実行し、差分を報告します。スコアは 100 語あたりの違反数で、同じテキストの別バージョンとの比較でのみ意味があります。約 50 語未満の場合はノイズです。一文だけの場合、または node が使えない場合は省略します。リンターが見るのは単語と文だけです。構成（パス 1）と 2 つの命名ルール（1 つのものには 1 つの名前、1 つの単語には 1 つの意味）は、人が読み取る必要があります。

散文以外

文体と各パスのルールは、文章を書くあらゆる場面に適用されます。場面ごとの特徴と書き換え方は、以下を参照してください。

• 書式（見出し、太字、リスト、絵文字、バッジ、スマート引用符）：formatting.md。
• 差分の説明をするコードコメント：code-comments.md。comment-stinky は詳細版です。コメントそのものが作業対象の場合に使ってください。
• 差分の理由ではなく、差分を言い換えているコミットメッセージと PR の説明：commits-and-prs.md。
• コード内の文字列（テスト名、エラーやログのメッセージ）：code-strings.md。
• 支援技術の利用を妨げたり、読者を排除したりする文章：inclusive-and-accessible.md。どちらもスロップとしては扱われませんが、どちらも欠陥です。
• あらゆる特徴についての文単位の修正前／修正後の例：prose.md。

過剰に修正しない

これらのルールは、根拠なく加えられた温かみや構成を取り除きます。冷たい文章や、まとまりのない文章を求めているわけではありません。

• 要点を支える構成は残します。 API リファレンスには多数の見出しが、仕様書には番号付きのセクションが、必須の PR テンプレートにはそのひな形が必要です。契約ではなく、過剰な部分を整理してください。
• 機械的になるほど簡潔にしません。 文の長さに変化をつけてください。5 語の文が連続するのも、それ自体が特徴です。
• リストにある語を避けるために、より悪い語を使いません。 「強い」という意味なら、「強力」で問題ありません。このルールが対象にするのは、「堅牢」を反射的に使うことであり、その背後にある考え方ではありません。
• 実際に役立つつなぎを削りません。 水増し表現は省き、読者が論理を追うのに必要なつなぎは残してください。
• 対比そのものを禁止しません。 実際の対比には「しかし」が必要な場合もあります。対象なのは誇張されたリズムであり、その言葉ではありません。
• 適切でない場面で STE を厳格に適用しません。 手順以外では、正確というより堅苦しく聞こえます。基本は、ニュアンスを残した表現にしてください。
• スコアを追い求めません。 違反がゼロでも、何も伝えていないことはあります。これらのルールが修正するのはスロップの形式であり、内容ではありません。

迷ったら、声に出して読んでみてください。理解していることを人が説明しているように聞こえるなら、そのままにしてください。宣伝文句のように聞こえるなら、直してください。