deslop

Deslop

AI 生成コードをコードベース全体にわたって徹底的にクリーンアップします。専門分野を絞った8つのパスで構成され、それぞれ新鮮な視点を持つサブエージェントが担当します。Shaw（@shawmakesmagic）のパターンに基づいています。

何をするか（8つのパス）

1. DRY／重複排除 — 複雑さを減らせる場合に、重複したコードを統合します
2. 共有型の統合 — 共有すべき型定義を統一します
3. デッドコードの削除 — スタックに適したツールで、参照されていないコードを見つけます
4. 循環依存の解消 — 循環を検出して解消します
5. 弱い型の削除 — any／unknown／T.untyped／interface{}を実際の型に置き換えます
6. 防御的な try/catch の削除 — 実質的な目的なくエラーを握りつぶしたり隠したりするエラーハンドラーを削除します
7. レガシー／非推奨／フォールバックコードの削除 — 現行のコードパスを1つに統合します
8. AI 由来の粗雑なコメントの削除 — 作業中の実況、スタブ、なりきり、コードから明らかな内容を説明するコメントを削除します

使用するタイミング

• AI による大規模なコーディングの後（短時間で大量のコードを生成したとき）
• 長期間作業している機能ブランチをマージする前
• 別の AI セッションや開発者から引き継いだコードベースで
• 定期的な徹底的なクリーンアップとして（四半期ごと、リリースごと）
• パイプラインでの位置：heavy AI coding → /deslop → /simplify → /adversarial-review → /finalize → commit

使用しないタイミング

• 些細な変更や最近の編集には使用せず、代わりに/simplifyを使用してください
• 慎重にレビューする時間がないコードベースでは使用しないでください。ファイルの移動やコードの削除が行われます
• 機能の開発中には使用せず、先に機能を完成させてください
• git ツリーがクリーンでない場合は使用しないでください（以下の「安全性」を参照）

安全性 — 絶対に守ること

このスキルはコードを削除します。実行する前に、必ず次のことを行ってください。

1. git ツリーがクリーンであることを確認する — git statusで変更がないことを確認してください。そうでなければ続行を拒否してください。コミットされていない変更がある場合は、ユーザーに退避またはコミットを依頼してください。
2. 専用ブランチを作成する — いずれかのパスで書き込みを行う前に、git checkout -b deslop/YYYY-MM-DDを実行してください。main/masterでは絶対に実行しないでください。
3. パスごとにコミットする — 各パスを個別にコミットしてください。そうすれば、残りをやり直さずに特定のパスだけを元に戻せます。
4. 確信度の高い変更だけを行う — 各サブエージェントは、確信のある変更だけを実装してください。判断が分かれる場合はコードを変更せず、人間によるレビュー用としてレポートに記載してください。
5. ツールをインストールする — パスに必要な標準ツールがインストールされていない場合は、インストールしてください。専用ツールがあるパスで、grep／ripgrepや手作業のスキャンに切り替えないでください。このスキルの目的は適切なアナライザーを使うことです。grepでは動的参照を検出できず、到達可能性解析も循環の検出もできません。以下の「ツールのインストール方針」を参照してください。

ツールのインストール方針

各パスには、スタックごとに標準ツールがあります（references/passes.mdおよび言語別リファレンスを参照）。サブエージェントはパスを開始するときにツールが利用可能か確認し、利用できない場合はインストールしてください。

JavaScript／TypeScript — npxでインストール不要

標準的なJS／TSツールはすべて、package.jsonを変更せずにnpx --yesで実行できます。

npx --yes knip        # dead code
npx --yes madge --circular src/   # circular deps

初回実行時に、npxはグローバルなnpmキャッシュにダウンロードします。プロジェクトは変更されません。これがデフォルトです。単発のdeslop実行のためにpackage.jsonへ何も追加しないでください。

Ruby — ユーザー用gemにgem install

gem install debride
bundle exec srb tc     # only if sorbet/config exists in the project

ユーザーのgemパスにインストールされます。単発のdeslop実行のためにプロジェクトのGemfileへ追加しないでください。

Go — $GOPATH/binにgo install

go install honnef.co/go/tools/cmd/staticcheck@latest
go install golang.org/x/tools/cmd/deadcode@latest

$(go env GOPATH)/binにバイナリをインストールします。Goの標準的なツール運用方法です。

インストールに失敗した場合（ネットワークがない、Goのバージョンがサポート対象外など）：失敗したこととツール名を報告し、そのパスをスキップしてください。grepで代用しないでください。パスをスキップしたという結果は正直な報告です。一方、grepベースの結果は誤解を招きます。分析したように見えても、専用ツールなら検出できる大半の問題を見逃すためです。

パスに正当な理由でツールが存在しない場合（例：packwerkを使わないRubyの循環依存、型システムを使わない環境での型の統合）は、その旨をパスのレポートで明示してください。「スキップ — 型システムを使用していないため」は適切な結果です。「スキップ — 代わりにgrepを実行」は適切ではありません。

入力の解析

$ARGUMENTS を解析します。

• 引数なし → リポジトリのルートで 8 つすべてのパスを実行します
• パス（例：app/services や src/）→ すべてのパスの対象をそのパスに限定します
• --dry-run → 各パスの調査フェーズを実行し、批判的な評価を出力しますが、コードは一切変更しません
• --passes 1,3,8 → 指定された番号のパスのみを実行します（カンマ区切り）
• --stack js|ruby|go → スタックを強制指定します（自動検出をスキップします）

ステップ 1：スタックの検出

対象のパス（パスが指定されていない場合はリポジトリのルート）でロックファイルを探します。

ファイル	スタック
package.json + tsconfig.json	typescript
package.json（TS 設定なし）	javascript
Gemfile	ruby（rails gem があるか確認 → rails）
go.mod	go

リポジトリに複数のスタックが含まれている場合があります（例：Vue フロントエンドを備えた Rails アプリ）。見つかったすべてのスタックを記録します。各パスをディスパッチするときは、対象ファイルに含まれるスタックをサブエージェントに伝えます。ネストされたフロントエンド（例：app/frontend/）の場合、パス 3 と 4 では、そのサブツリーに対して JS/TS 対応のサブエージェントをディスパッチし、残りには Ruby 対応のサブエージェントをディスパッチします。

--stack が指定されている場合は、検出をスキップして強制指定されたスタックを使用します。

スタック固有のツールの詳細（コマンド、インストール、注意点）については、そのツールを使用するパスの実行直前に、該当するリファレンスファイルのみを読み込みます。

• references/javascript.md — knip、madge、TypeScript の型チェック
• references/ruby.md — debride、packwerk、Sorbet に関する注意点
• references/go.md — staticcheck、go mod graph、deadcode

ステップ 2：調査フェーズ（並列、読み取り専用）

対象範囲内の（--passes でスキップされていない）各パスについて、同じターン内でサブエージェントをディスパッチし、8 つすべての調査タスクを並列実行します。

subagent_type: general-purpose を指定して Agent ツールを使用します。各調査サブエージェントは次を行います。

• コードの読み取りのみを行い、編集はしません
• 読み取り専用の解析ツールを実行します（リンター、knip --dry-run、madge --circular など）
• 批判的な評価を作成します。問題点、該当箇所、確信度、修正方法を記載します
• 各指摘を 確信度が高い（安全に自動適用できる）または 要レビュー に分類します
• 構造化されたレポートを返します

調査サブエージェントのプロンプトテンプレート（{pass_name}、{pass_instructions}、{stack_info}、{scope_path} を埋めてください）。

You are a senior engineer performing a cold read of this codebase. You are
scoped to a single concern: {pass_name}.

## Stack Info
{stack_info}

## Scope
Target path: {scope_path}

## Your Mandate
{pass_instructions}

## Output Format

Return two sections:

### Critical Assessment
A prose summary of the state of the code for your concern. What patterns do
you see? How pervasive is the problem? Any notable surprises?

### Findings
A list of concrete, actionable findings. For each finding, provide:

- **Location:** file path(s) and line range(s)
- **Issue:** what's wrong
- **Fix:** specific, concrete change
- **Confidence:** high | needs-review
- **Rationale:** why this is safe (for high-confidence) or what the risk is (for needs-review)

Be honest about confidence. If you can't verify a symbol is unused across the
whole codebase, it's needs-review. If removing a try/catch might swallow a real
error condition, it's needs-review. When in doubt, err toward needs-review.

## Do Not
- Make any file edits
- Run stateful commands (git commits, migrations, package installs)
- Go beyond your concern's scope

各パスの詳しい手順、スタックに応じたツールの実行方法、各パスで確信度が高いとみなされる条件については、references/passes.md を参照してください。

ステップ 3：適用フェーズ（順次実行、パスごとに 1 コミット）

--dry-run の場合は、このステップをスキップしてレポートに進みます。

確信度の高い指摘があるパスについて、次の順序で実行します。

1. デッドコード（パス 3）を最初に — 未使用コードを削除すると、後続のパスで扱う範囲が縮小します
2. AI スロップコメント（パス 8） — コメントのリスクは低いです
3. レガシー／非推奨（パス 7）
4. 防御的な try/catch（パス 6）
5. 弱い型（パス 5）
6. 共有型の統合（パス 2）
7. DRY／重複排除（パス 1） — 最も影響が大きいため、他のパスで整理した後に実行します
8. 循環依存（パス 4） — 構造的な変更のため、最後に実行します

各パスで次を行います。

1. 適用サブエージェントをディスパッチします。調査パスで得られた指摘を渡し、確信度の高い項目のみを実装するよう指示します。ファイルの内容は最新のものを渡します（調査フェーズでキャッシュされた状態に依存しないでください）。
2. サブエージェントの応答後、プロジェクトの型チェッカー／リンター／テストスイートが利用可能であれば実行し、合格／不合格を記録します
3. deslop: <pass_name> というメッセージでコミットします（例：deslop: remove dead code）
4. テストまたは型チェックが失敗した場合、次のパスには進まず、失敗を報告してユーザーに引き継ぎます

適用サブエージェントのプロンプトテンプレート：

You are implementing a single cleanup pass: {pass_name}.

## Stack Info
{stack_info}

## Findings to Apply
{high_confidence_findings}

## Rules
- Implement ONLY the findings above. Do not expand scope.
- If a finding looks wrong on closer inspection, skip it and note why in your
  report. Safety over completeness.
- Make minimal edits. Don't reformat, rename, or touch surrounding code.
- If a finding would break a public API, skip it and flag it.

## Output
Return a summary:
- Applied: N findings
- Skipped: N findings (with brief reason for each)
- Files touched: list

ステップ 4：レポート

すべてのパスの完了後（または --dry-run の調査後）、単一のレポートを作成します。

## Deslop Report

**Stack:** <detected stacks>
**Scope:** <path>
**Mode:** <full | dry-run | --passes 1,3,8>
**Branch:** deslop/YYYY-MM-DD (or "no changes — dry-run")

### Pass Summary
| Pass | Findings | High-Conf | Applied | Needs-Review | Skipped |
|------|----------|-----------|---------|--------------|---------|
| 1. DRY/dedupe | ... | ... | ... | ... | ... |
| 2. Shared types | ... | ... | ... | ... | ... |
| 3. Dead code | ... | ... | ... | ... | ... |
| 4. Circular deps | ... | ... | ... | ... | ... |
| 5. Weak types | ... | ... | ... | ... | ... |
| 6. Defensive try/catch | ... | ... | ... | ... | ... |
| 7. Legacy code | ... | ... | ... | ... | ... |
| 8. AI slop comments | ... | ... | ... | ... | ... |

### Needs-Review Items
Grouped by pass. Each item includes location, issue, suggested fix, and why
it was deferred. Review these manually.

### Commits
List of commits created on the branch.

### Next Steps
- Review needs-review items
- Run the full test suite
- Run `/simplify` + `/adversarial-review` before merging

よくある間違い

• 作業ツリーが汚れた状態で実行する。 各パス間でコミットするのは、きれいに元に戻せるようにするためです。作業ツリーのクリーンチェックを省略すると、問題のあるパスがユーザーの進行中の作業と混ざり、切り分けが非常に困難になります。
• 調査フェーズを省略する。 すぐに編集を始めると、表面的な、パターンに当てはめただけの変更になります。まず調査して、調査結果をコミットしてから適用してください。
• 要レビュー項目を適用する。 サブエージェントが確信を持てなかったのであれば、適用フェーズでも確信を持つべきではありません。レポートに記載し、ユーザーに判断を委ねてください。
• パス 3（デッドコード）より先にパス 1（DRY）を実行する。 削除予定のコードを重複排除することになり、労力が無駄になります。
• 適用時にすべてのパスを並列実行する。 パス同士が競合する可能性があります（たとえば、型の統合によって移動した型を、デッドコードのパスが削除しようとする場合があります）。調査は並列で行い、適用は順番に行ってください。
• インストールの失敗を処理の妨げとみなす。 パスのツールをインストールできない場合（ネットワークがない、バージョンがサポート対象外など）、そのパスでは「スキップ — のインストールに失敗」と報告し、残りの実行を続行してください。

参考資料

• Shaw による元のプロンプト：https://x.com/shawmakesmagic/status/2044269097647779990
• references/passes.md — パスごとの詳しい手順
• references/javascript.md — JS/TS ツール（knip、madge）
• references/ruby.md — Ruby/Rails ツール（debride、packwerk）
• references/go.md — Go ツール（staticcheck、go mod graph）