de-slop

De-Slop

AI 支援開発では、3 種類のスロップが生まれます。コードのスロップはコンパイルできても、機械が書いたように読めるコードです。プロダクトのスロップはリリースされていても、料金を支払う顧客には未完成に感じられるものです。文章のスロップは、誇張表現、エムダッシュの多用、チャットボット風の言い回し、書き手の声が感じられない中立的な文体など、AI 特有の兆候がある文章です。このスキルは、これら 3 種類すべてを取り除きます。デフォルトではコードのスロップを対象とします。--product を指定するとプロダクトのチェックも追加されます。prose は文章のチェックを実行します。ui はデザインシステムのチェックのみを実行します。

コードを編集・削除するため、確認ゲートを設け、ブランチの差分を優先します。読み取り専用で指摘のみを行う場合は、structural-review ／/review を使用してください。階層化されたドキュメント標準（Diátaxis、STE、Global English）を適用する場合は、technical-writing を使用してから、ここにある文章カタログを適用してください。

文章カタログを必要とするほかのスキルは、 references/prose-slop.md を参照してください。それらのスキルからこのスキルが実行されることはありません。

契約

入力：

• 整理するパッケージ、リポジトリ、または文章。任意でスコープ（--changed、all、dry-run）と対象（--product、ui、prose）を指定できます。

出力：

• 適用した編集（dry-run の場合は、変更予定箇所をまとめたレポート）と、種類別に削除した成果物の簡潔な件数。

作成／変更するもの：

• ソースファイルまたは指定された文章を編集します。エントリーポイント、設定ファイル、README は削除しません。

外部への副作用：

• ローカルファイルの編集以外はありません。コードを編集した後に型チェックとテストを実行します。

確認が必要な場合：

• ツリー全体を一括処理する場合（all）、または意図が曖昧なプロダクトの文章を書き換える場合は、事前に確認が必要です。

委任先：

• 構造上のスロップを取り除いた後の最終的な細部調整には polish。
• 修正が機械的な削除ではなく、実際のリファクタリングとなる場合は refactor-code。
• 依頼がスロップの削除ではなく、ドキュメント、RFC、README、PR、コミットの標準に関するものなら technical-writing。

コードのスロップ（デフォルト）

周囲のファイルで使われているスタイルに合わせて、以下を削除します。

1. コンソール出力 → プロジェクトのロガーに置き換えます。
2. any 型 → 適切な型、または型ガードを組み合わせた unknown に置き換えます。
3. 未使用のインポート／変数 → 削除します。
4. コメントアウトされたコード → 削除します（git が記録しています）。
5. デバッグ用／一時的なコード → 残っている TODO／FIXME のデバッグ行を削除します。
6. 冗長なコメント — 何をしているかを言い換えるコメントは削除し、なぜそうするかを説明するコメントは残します。
7. 不要な防御的チェック — 失敗し得ない信頼された内部経路の try-catch と null ガードは削除し、実際の外部境界にあるガードは残します。
8. 過度なネスト — 深くネストした if/else のピラミッドを早期リターンに置き換えて簡潔にします。

文章のスロップ（prose）

最初の引数が prose の場合、または対象が返信、README、RFC、PR の説明、コミットメッセージなどの文章である場合は、 references/prose-slop.md を適用します。

1. 31 のパターンを確認します。
2. 意味を保ち、意図されたトーンに合わせて書き直します。
3. 独自性を加えます。見解を示し、リズムに変化をつけ、具体的な事実を盛り込みます。
4. 自己監査します。「これが明らかに AI 生成だと分かる点は何か？」と問いかけ、残っている兆候を修正します。

--product による文章の整理にも、このカタログを適用します。意図が不明な場合は、プロダクトの文体を勝手に作らず、指摘してください。

プロダクトのスロップ（--product）

アプリが完成していると感じられるかどうかを左右するレイヤーです。すべての「誤り → 正しい」カタログについては references/product-slop.md を参照してください。以下の 3 つの分類があります。

• 文章 — マーケティング的な水増し表現、ありきたりな AI 風の言い回し、役に立つ情報がない空状態やエラーメッセージ。すべての文字列に文章カタログを適用します。
• UI — 手を加えていない shadcn に紫のグラデーションを組み合わせた見た目、一貫性のない余白や角丸、スタイルが未設定、または存在しないローディング状態やエラー状態。
• UX — 何にもつながっていないボタン、行き止まりになるフロー、実在しそうなナビゲーションの裏にあるプレースホルダーのページ、バリデーションや成功時のフィードバックがないフォーム。

プロダクトのスロップの処理には、削除だけでなく判断が必要です。意図された文章や動作を推測せず、曖昧な点は指摘してください。

UI の余計な要素（ui）

最初の引数が ui の場合は、UI のチェックのみを実行します。先にコードの整理ワークフローを実行しないでください。

このスキルにコンポーネント固有のスタイルルールを組み込まないでください。対象プロジェクトからルールを導き出してください。

デザインを評価する前に、ローカルの信頼できる情報源を確認してください。

• デザインドキュメント、トークン、テーマファイル、CSS 変数、Tailwind 設定、または同等のもの。
• カード、ボタン、入力欄、ダイアログ、テーブル、タブ、ナビゲーション、バッジ、ツールチップ、メニュー、読み込み状態などの共有 UI プリミティブ。
• 同じアプリまたはパッケージ内の、近接する良質な例を 3 つ。
• 対象画面／コンポーネントのコードと、利用可能な場合はレンダリング結果。

短い作業用インベントリを作成してください。

• 承認済みのトークンと、スペーシング／角丸／シャドウのパターン。
• 共有プリミティブとそのバリエーション。
• 監査対象のサーフェスにおける UI の役割の対応表：プリミティブ、ドキュメント化されたレシピ、または未整備。
• すでに本番品質に見えるローカルの例。
• 影響を受ける対象ファイルとルート。

監査対象のサーフェスにある UI の各役割について、プロジェクトに共有プリミティブまたはドキュメント化されたレシピがあるかを特定してください。

• サーフェス、カード、パネル。
• ボタンまたはアクション。
• リンクまたはナビゲーション。
• 入力欄、セレクト、テキストエリア。
• チェックボックス、ラジオボタン、スイッチ。
• バッジまたはステータス。
• モーダル、ダイアログ、ドロワー、ポップオーバー、ツールチップ。
• テーブル、リスト、グリッド。
• タブまたはセグメントコントロール。
• 空、読み込み、エラーの各状態。
• アプリシェル、ナビゲーション、レイアウトセクション。

プリミティブが存在する場合：

• 生の HTML、コピーしたマークアップ、またはローカルスタイルではなく、プリミティブを使用してください。
• 公開されている props、バリエーション、スロット、ドキュメント化された構成パターンのみを使用してください。
• 呼び出し元で、背景、ボーダー、角丸、シャドウ、タイポグラフィ、スペーシング、フォーカス、無効状態、読み込み状態、または状態のスタイルといった、プリミティブの中核となるビジュアル上の仕様を上書きしないでください。
• 必要なバリエーションが存在しない場合は、そのニーズが明確で再利用可能なときに限り、プリミティブに名前付きのバリエーションを追加してください。それ以外の場合は、指摘事項として先送りしてください。

プリミティブが存在しない場合：

• ドキュメント化されたデザインレシピ、または近隣のローカルパターンの中で最も確かなものに従ってください。
• 同じレシピが繰り返し使われている場合は、プリミティブまたは名前付きバリエーションとして抽出することを提案してください。
• ユーザーが特注デザインを明示的に求めていない限り、その場限りのビジュアル表現を作らないでください。

ドキュメント構造や文章には、生のセマンティック HTML を使用しても問題ありません。デザインシステムのコントロールやサーフェスとして機能する場合、生の HTML は適切ではありません。

主観的な好みより先に、客観的なデザインシステムからの逸脱を修正してください。変更は監査対象のサーフェスに限定し、意図を推測して作り込むのではなく、具体的な指摘事項とともに、プロダクト上の判断を先送りしてください。

ワークフロー

1. モードの振り分け — ui は UI のチェックを実行して終了します。prose は文章のカタログを実行して終了します。--product はコードの余計な要素を整理した後に、プロダクトと文章のチェックを追加します。

2. 構造の検出 — モノレポか単一パッケージかを確認します（ls packages/ 2>/dev/null）。パッケージごとに個別に処理します。

3. 対象範囲 — --changed では、編集をブランチの差分に限定します。

   BASE="$(git merge-base HEAD origin/HEAD 2>/dev/null || git merge-base HEAD main 2>/dev/null || git merge-base HEAD master)"
   git diff --name-only "$BASE"..HEAD    # files this branch touched
   

   そのファイル／ハンクのみを変更してください。このモードでは、他の場所にある既存の余計な要素を整理しないでください。

4. 除去 — 上記のカテゴリに従って除去します。

5. 検証 — コードを変更した場合は、引き続きビルドが成功し、次のチェックに合格する必要があります。

   bun run type-check || bunx tsc --noEmit
   bun run test
   

6. 記録 — クリーンアップしたパッケージと種類ごとの件数が、現在のリポジトリのセッションログに記録されている場合は、そこに記録します。

モード

• default — コードの余計な要素を対象に、現在のパッケージを編集します。
• ui — UI／デザインシステムのプリミティブをチェックします。
• prose — 文章の特徴をカタログ化する処理のみを実行します。
• --changed — このブランチで追加されたファイル／ハンクのみを対象にします（PR に最も安全な設定です）。
• --product — プロダクト上の余計な要素（コピー／UI／UX）のチェックと、文章のカタログ化を追加します。
• all — モノレポ内のすべてのパッケージを対象にし、それぞれ個別に処理します。
• dry-run — 検出のみを行います。編集はせず、種類ごとにグループ化した件数とともに、見つかったすべての項目を報告します。任意の対象範囲と組み合わせられます。

アンチパターン

• ブランチの範囲に限定するはずが、ツリー全体を整理する — --changed を使えば PR をレビューしやすくなります。ツリー全体を編集する場合は、確認が必要です。
• 副作用のあるインポート（CSS、ポリフィル）や重要なファイル （README、設定ファイル、エントリーポイント）を削除する。
• 冗長に見えるという理由で「なぜ」を説明するコメントを削除する — 削除するのは 何をするかを言い換えただけのコメントに限ります。
• 製品コピーや意図された動作を推測する — 曖昧な製品関連の不要な記述は修正をでっち上げず、ユーザーに確認します。
• 整理を名目にロジックを書き換える — 動作の変更はリファクタリング（refactor-code）であり、不要な記述の整理ではありません。
• 削除後に生気のない文章を残す — 無機質な文章も、依然として不要な記述です。