absolute-prune

最初の応答は✂️の絵文字で始めてください。

Absolute Prune

リポジトリから不要なものを取り除きます。未使用の依存関係、参照されていないエクスポート、到達不能なコード、孤立したファイルが対象です。エビデンスに基づき、参照がないことを証明するツールで各削除を裏付け、安全な段階に分けて適用し、各段階でテストを成功させます。

references/health-engine.md の共有エンジンを実行します。DETECT → SCAN → TRIAGE → FIX → VERIFY → REPORT のループと安全性に関する契約については、こちらをお読みください。このファイルでは、プルーニングに固有の内容のみを扱います。

---

使用する場面

• 「デッドコードを削除して」「未使用の依存関係を整理して」「何を削除できますか？」。
• どこからもインポートされなくなったパッケージによる、バンドルやインストールの肥大化。
• リファクタリング後に残った孤立ファイル：機能の経路変更後に残されたファイルやエクスポート。

prune と simplify の違い： simplify は 作業中の git diff を整えます。prune はコミット済みリポジトリ全体を対象に、リポジトリ全体で不要なものを洗い出します。変更作業の途中では simplify を、クリーンな main で定期的に整理するときは prune を使用します。

---

スキャン対象

不要な依存関係 — 宣言されているが一度もインポートされていない依存関係（および、インポートされているが宣言されていない依存関係の不足）：

エコシステム	ツール
JS/TS	depcheck または knip（knip はエクスポート／ファイルも対象）
Python	deptry
Go	go mod tidy（差分）、未使用モジュールの検出

デッドコード — 参照されていないエクスポート、到達不能な分岐、孤立したファイル：

エコシステム	ツール
JS/TS	knip（エクスポート／ファイル）、ts-prune、eslint no-unused-vars
Python	vulture、ruff の未使用ルール
Go	deadcode ./...、staticcheck（U1000）

プロジェクトですでに使われているツールを優先してください。結果は 候補 として扱い、削除する前に、動的インポート、リフレクション、DI、公開 API、設定文字列を介して参照されていないことを確認してください。

---

リスクのランク付け（TRIAGE）

段階	削除対象	デフォルト
1	未使用の devDeps、参照されていない ローカルの エクスポート／関数	すぐに修正 — リスクが最も低い
2	未使用のランタイム依存関係、孤立した内部ファイル	動的参照がないことを確認した後、このパスで修正
3	公開 API、プラグインシステム、動的 require、リフレクション、または設定から到達可能なもの	要確認／通常は保留 — 誤検出のリスクが高い

静的ツールは動的参照を見落とします。段階 3 のもの、またはツールが指摘していても不要だと 証明できない ものは、ユーザーに確認するか保留にします。自動で削除してはいけません。

---

修正と検証

• 小さく、元に戻せる段階に分けて削除します。各段階ではカテゴリを1つに絞ります（例：「未使用の devDeps」、次に「孤立したファイル」）。
• 各段階の後に、テスト、ビルド、型チェックをすべて実行します。型チェックとビルドが成功することが、削除したシンボルに実際に参照がなかった証拠になります。何かが失敗した場合、そのシンボルは不要ではなかったということです。元に戻して分類し直してください。
• 依存関係を削除するときは、マニフェストから削除し、ロックファイルを再生成して、再ビルドします。
• 生成ファイル、ベンダーコード、公開 API の範囲、または追跡できない設定／プラグインの動作に不可欠なものは削除しないでください。これらは「デッドコードの疑いあり。人による判断が必要」として報告します。設定の preferences.health.protectedPaths は削除禁止の glob として扱います。ツールが指摘していても、一致するものは対象外です。

---

注意点

1. ツールを盲信する。 動的インポート、DI コンテナー、リフレクション、文字列キーによるルックアップは静的解析をすり抜けます。削除する前に確認してください。
2. 公開 API を削除する。 ライブラリ内部で使われていないエクスポートが、そのライブラリの本来の目的である場合もあります。パッケージのエントリーポイントと exports マップを確認してください。
3. 生成ファイルやベンダーコードを削除する。 孤立しているように見えても、意図的に再生成またはチェックインされているものです。
4. 一度にすべてを削除する。 指摘されたものをすべて1つのコミットで削除すると、リグレッションの二分探索ができなくなります。段階に分けて実施してください。
5. リファクタリングに範囲を広げる。 prune は不要なものを削除します。生きているコードの構造は変更しません。構造の変更には simplify または work を使用してください。

---

補助コマンド

• /absolute simplify — 差分内の 稼働中 のコードを再構成して明確にする場合に使用します。
• /absolute upgrade — 相性のよい組み合わせです。未使用の依存関係を削除してから、残ったものをアップグレードします。
• /absolute debt — 削除によって、lint や未使用変数に関する警告もまとめて解消できることがよくあります。