Diet削除評価: $ARGUMENTS

5段階のデータ駆動型フレームワークを使用して、$ARGUMENTSを削除する価値があるかどうかの深い評価を行います。このコマンドはuzomuzo dietが終わるところから始まります。dietは優先度のランキングを提供し、このコマンドは削除の判定を提供します。

使用時期: uzomuzo dietが依存関係をランク付けした後、削除に投資する価値があるかどうかを決定する必要があるとき。難易度に関係なく機能します。簡単な依存関係は迅速な確認を得られ、難しい依存関係は具体的なマイグレーション計画を得られます。

他のスキルとの関係:

• uzomuzo diet はランキングと難易度を提供します(自動化、すべての依存関係を一度に)
• /diet-evaluate-removal は削除する価値があるかどうかとその方法を提供します(LLM駆動、一度に1つの依存関係)
• /diet-assess-risk は保持することがどのくらい危険かを提供します(LLM駆動、セキュリティに焦点)
• /diet-remove は削除を実行します(LLM駆動、実装)

---

Phase 1: Diet データの取得

対象の依存関係のdiet JSONエントリを抽出します。dietの再実行よりも既存のJSONを優先します。

オプションA - 既存のdiet JSON(推奨):

jq '.dependencies[] | select(.name == "$ARGUMENTS")' diet.json

オプションB - 今すぐdietを実行:

uzomuzo diet --sbom bom.json --source . --format json | jq '.dependencies[] | select(.name == "$ARGUMENTS")'

抽出する必須フィールド

diet JSONからこれらのすべてを表示します。何も再計算しないでください。

フィールド	意味
name / version / ecosystem	依存関係の識別子
purl	正規パッケージURL識別子
scope	依存関係スコープ: "tool"(ビルド時のみ)、"runtime"(リフレクション/ServiceLoaderロード)
rank / priority_score	削除優先度リストでのこの依存関係の位置
difficulty	trivial / easy / moderate / hard
exclusive_transitive / total_transitive	一緒に削除される依存関係 / 合計推移的依存関係数
stays_as_indirect	直接使用の削除後も残るかどうか
indirect_via	どの他の依存関係が推移的に引き込むか
import_file_count	この依存関係をインポートするファイル数
call_site_count	すべてのファイル全体での総呼び出しサイト数
api_breadth	使用される異なるAPI数
symbols	使用されるAPIサーフェス(関数/型名)
import_files	このdependencyをインポートする正確なファイルパス
has_blank_import / has_dot_import / has_wildcard_import	特別なインポートパターン
is_unused	dietがインポートがないことを検出したかどうか
lifecycle	Active / Stalled / Legacy-Safe / EOL-Confirmed / EOL-Effective / EOL-Scheduled / Archived / Review Needed
has_vulnerabilities / vulnerability_count / max_cvss_score	セキュリティシグナル
overall_score	複合的なヘルススコア(OpenSSF Scorecard)
graph_impact / coupling_effort / health_risk	スコアコンポーネント

データ品質チェック

続行する前に、これらのパターンのいずれかにフラグを立ててください - これらはdietのカップリングデータが信頼できないことを示しています:

• scope: "tool" + import_file_count: 0 -- ビルド時のみのツール依存関係では予想されます。IBNCパターンではありません。これらは設計上、ランタイムインポートがゼロです。
• scope: "runtime" + import_file_count: 0 -- ランタイムメカニズム依存関係(JDBCドライバ、ロギングバックエンド、Spring自動設定)では予想されます。静的インポートではなく、リフレクション/ServiceLoader/クラスパスを介してロードされます。
• has_blank_import: true + call_site_count: 0 -- 空のインポート自体が使用(Goデータベースドライバ、JSポリフィル)です。カップリングは過小評価されています。
• has_wildcard_import: true -- すべてのシンボルがスコープ内です。api_breadthは過小計算されるかもしれません。
• has_dot_import: true -- 広く結合されています。シンボルはパッケージ修飾子がありません。
• import_file_count > 0 + call_site_count: 0(空白/ドット/ワイルドカードフラグなし) -- 可能なIBNCパターン(型のみ使用、アノテーション処理、フレームワークDI、設定駆動プラグイン)。「0呼び出し」を信頼する前に調査してください。注: 上記の空のインポートパターンとは異なります -- 空のインポートは通常call_site_count = 1を生成し、0ではありません。

---

Phase 2: 使用法の分類

import_filesの各エントリをプロジェクトでの役割によって分類します。これが単一で最も重要なステップです - 削除の実質的な難易度を決定します。

分類カテゴリ

カテゴリ	パスパターン	インパクト
Production	src/, lib/, internal/, pkg/, cmd/, app/(test/下にない)	完全なマイグレーション必須
Test	*_test.go, test/, tests/, __tests__/, spec/, *.test.ts	独立して削除または交換可能
CI / インフラストラクチャ	.github/, scripts/, ci/, Makefile, build/	通常は簡単に置換可能
Example / Demo	examples/, example/, demo/, sample/	独立して削除または更新可能
生成済み	// Code generatedヘッダ付きファイル、*_gen.go, *.pb.go	置換で生成器を再実行
Vendored	vendor/, node_modules/, third_party/	分析から除外 -- 依存関係のコピー、使用ではない

出力形式

Usage Classification for {name}:
  Production:     {N} files  [{file list}]
  Test:           {N} files  [{file list}]
  CI/Infra:       {N} files  [{file list}]
  Example:        {N} files  [{file list}]
  Generated:      {N} files  [{file list}]

  Effective scope: {N} production files (out of {total} total)

実質的な難易度の調整

diet難易度	すべてのファイルがテスト/CI/example	調整後の難易度
hard	はい	easy(本番コードへの影響なし)
moderate	はい	trivial
easy/trivial	--	変更なし

すべてのインポートファイルが本番以外の場合、注記: 「本番コードへの影響なし。」

---

Phase 3: 実現可能性分析

dietが自動化できない2つのチェック: APIリークage(バイナリゲート)とシンボル置換可能性(ドメイン知識が必要)。

3a. APIリークageチェック(ゲート)

重要な質問: この依存関係のタイプは、エクスポートされた識別子に現れていますか?

• はい の場合 -- 削除するのは、ダウンストリームコンシューマの破壊的な変更です。すぐにこれにフラグを立ててください。判定は破壊的な変更のコストを考慮する必要があります。
• いいえ の場合 -- 内部交換、APIへの影響なし。

エクスポートされた関数シグネチャ(パラメータ型、戻り値型)、エクスポートされた構造体フィールド型、およびエクスポートされたインターフェースメソッドシグネチャのパッケージのタイプを探します。関数本体内の内部使用はAPIリークageではありません。

エコシステム別チェック方法:

エコシステム	チェック対象
Go	エクスポートされた関数シグネチャ、構造体フィールド、および依存関係のタイプを参照するインターフェースメソッド。非テストファイルで型の位置の依存関係のパッケージ名を検索します。
npm/TS	export ... from '{pkg}'の再エクスポート、またはdependencyのタイプを使用したエクスポートされた型/インターフェース。
Python	__init__.pyファイルの再エクスポート: from {pkg} import ...これは公開APIの一部です。
Java/Maven	依存関係のパッケージを参照するテスト以外のソースセット内の、公開クラスシグネチャ、メソッドパラメータ、戻り値型、またはフィールド型。

3b. シンボルマイグレーションマップ

dietのsymbolsリストを使用して、各シンボルの置換可能性を分類します。ここがLLMが最も価値を追加するところです。

Symbol Migration Map for {name}:

| Symbol | Category | Replacement | Notes |
|--------|----------|-------------|-------|
| {sym1} | stdlib   | {specific function} | Available since {version} |
| {sym2} | existing-dep | {dep already in project} | Already in go.mod/package.json |
| {sym3} | self-impl | {N}-line implementation | Non-crypto, well-defined |
| {sym4} | no-replacement | -- | Crypto/protocol, keep or find alternative lib |

Summary: {N}/{total} stdlib, {N} existing-dep, {N} self-impl, {N} no-replacement.

シンボル分類のルール:

• stdlib: これを優先します。特定の関数に名前を付けます(例: os.UserHomeDir()、slices.SortFunc())。必要な最小言語バージョンを注記します。
• existing-dep: プロジェクトに既に存在する依存関係がこれを提供します。新しい依存関係は追加されません。
• self-impl: 暗号化、プロトコル、セキュリティ機能以外のみです。テストを含むコード行数を推定します。
• no-replacement: シンボルは実行可能な代替手段がありません。機能を削除できない限り、これは削除をブロックします。

特殊なケース:

• is_unused: trueの場合 -- このステップをスキップします。依存関係は単に削除できます。
• has_blank_import: true + call_site_count <= 1の場合 -- インポート自体が使用(ドライバ登録、ポリフィル)です。init()が何をするかを確認してください。置換は通常、コード変更ではなく、別のドライバパッケージです。ドロップイン代替ドライバ/ポリフィルが存在する場合は置換可能性をHighと評価し、存在しない場合はLowと評価します。
• symbolsが空だがimport_file_count > 0(空白/ドット/ワイルドカードフラグなし) -- dietのカップリング分析は不完全かもしれません。実際のAPI使用法を決定する前にインポートファイルを手動で調査し、置換可能性を評価します。根拠の分析のギャップに注記します。

---

Phase 4: 6軸定量スコアリング

Phases 1-3で収集されたデータを使用して、各軸をHigh/Med/Lowで評価します。各軸は具体的なデータに基づいています -- 推測ではありません。

軸	データソース	High(削除を好む)	Medium	Low(削除を阻止)
推移的クリーンアップ	exclusive_transitive	>= 10の排他的依存関係	1-9の排他的	0の排他的
本番スコープ	Phase 2分類	0個の本番ファイル(すべてテスト/CI/example)	<50%の本番ファイル	>= 50%の本番ファイル
カップリング深度	coupling_effort、import_file_count、call_site_count	coupling_effort < 0.25(trivial/easy)	0.25 - 0.6(moderate)	>= 0.6(hard、深く組み込まれている)
置換可能性	Phase 3bシンボルマップ	> 80%のシンボルにstdlib/existing-dep置換がある	50-80%が置換可能	< 50%、または暗号化/プロトコルが関与
セキュリティ緊急性	has_vulnerabilities、max_cvss_score、lifecycle	CVSS >= 7.0、またはライフサイクルEOL-Confirmed/EOL-Effective/Archived	CVSS 4.0-6.9、またはライフサイクルStalled/EOL-Scheduled/Review Needed	脆弱性なし、ライフサイクルActive/Legacy-Safe
カスケード可能性	exclusive_transitive、プロジェクト知識	削除によって3個以上の削除がアンロック	1-2個をアンロック	スタンドアロン、カスケードなし

スコアリングオーバーライド

• カップリング深度オーバーライド: Phase 2がすべてのインポートファイルが本番以外(テスト/CI/example)であることを示す場合、coupling_effortに関わらずカップリング深度をHighにオーバーライドします。テスト/CIリファクタリングは呼び出し数に関わらず低リスクです。
• 推移的クリーンアップの警告: stays_as_indirect: trueの場合、exclusive_transitiveは実際のクリーンアップを過大評価するかもしれません -- いくつかの「排他的」推移物は間接的パスを介して到達可能なままかもしれません。根拠分析のこの不確実性に注記します。

スコアリング出力

6-Axis Scores:
  Transitive Cleanup:  {H/M/L} -- {exclusive_transitive} exclusive deps ({reasoning})
  Production Scope:    {H/M/L} -- {N}/{total} files are production ({reasoning})
  Coupling Depth:      {H/M/L} -- effort={coupling_effort:.2f}, {call_site_count} calls across {api_breadth} APIs
  Replaceability:      {H/M/L} -- {N}/{total} symbols replaceable ({reasoning})
  Security Urgency:    {H/M/L} -- {lifecycle}, {vulnerability_count} vulns, max CVSS {max_cvss_score}
  Cascade Potential:   {H/M/L} -- {reasoning}

---

Phase 5: 判定

すべてのphaseを構造化した推奨事項に統合します。diet JSONの正確なフィールド名を使用します。

### Verdict: {name}@{version}

**Diet Data**:
  rank: #{rank}
  priority_score: {priority_score:.3f}
  difficulty: {difficulty}
  ecosystem: {ecosystem}

**Graph**:
  exclusive_transitive: {exclusive_transitive}
  total_transitive: {total_transitive}
  stays_as_indirect: {stays_as_indirect}
  indirect_via: {indirect_via or "none"}

**Coupling**:
  {import_file_count} files ({N} production, {N} test, {N} other)
  {call_site_count} calls across {api_breadth} APIs
  symbols: {symbols count} ({N} stdlib-replaceable, {N} self-impl, {N} no-replacement)

**Health**:
  lifecycle: {lifecycle}
  vulnerabilities: {vulnerability_count} (max CVSS {max_cvss_score})

**API Leakage**: {Yes (BREAKING CHANGE) / No}

**6-Axis Summary**:
  {axis}: {H/M/L}  (x6, from Phase 4)

**Recommendation**: REMOVE / DEFER / KEEP
**Effort**: Trivial (<1h) / Small (1-4h) / Medium (1-3d) / Large (1w+)
**Priority**: S (do now) / A (this sprint) / B (when convenient) / C (keep for now)
**Rationale**: {1-2 sentences -- why this recommendation, citing the key axis scores}

推奨ロジック

ルールは上から下へ評価されます。最初にマッチしたものが優先されます。 複数の行がマッチする可能性がある場合、より前の行が優先されます。

条件	推奨
is_unused: true	REMOVE、Trivial、Priority S
APIリークage = Yes AND セキュリティ緊急性 = High	REMOVE(破壊的な変更警告付き) -- セキュリティはAPI安定性よりも優先されます。根拠は破壊的な変更を文書化し、メジャーバージョンバンプまたは廃止期間を推奨する必要があります。/diet-assess-riskにエスカレートします
APIリークage = Yes	DEFER(メジャーバージョンバンプまたは廃止期間が必要)
置換可能性 = Low(暗号化/プロトコル)	KEEP -- 自己実装するのではなく、別の保守されたライブラリを見つけてください。セキュリティ緊急性も高い場合は、完全なリスク分析のために/diet-assess-riskにエスカレートします。暗号化/プロトコルの自己実装は絶対に推奨しません
6軸がすべてHighまたはMed	REMOVE
1-2軸がLow、残りHighMed	REMOVE -- 根拠分析でLow軸を注意事項として注記します
セキュリティ緊急性 = High、その他混合	REMOVE(セキュリティを優先)。完全な分析のために/diet-assess-riskを提案します
>= 3軸がLow	KEEP
stays_as_indirect: true、カップリング低	REMOVE(依然価値あり: バージョン管理を委譲、将来のクリーンアップをアンロック)

作業量の導出

作業量	基準
Trivial (<1h)	is_unused: true、OR 0個の本番ファイル、OR すべてのシンボルがstdlib置換可能で<= 3ファイル
Small (1-4h)	<= 5個の本番ファイル AND > 80%シンボルが置換可能
Medium (1-3d)	6-15個の本番ファイル、OR 50-80%シンボルが置換可能、OR 廃止が必要なAPIリークage
Large (1w+)	> 15個の本番ファイル、OR < 50%シンボルが置換可能、OR 暗号化/プロトコル置換が必要

さらなる分析を推奨する場合

• セキュリティ緊急性 = High --> 「完全なデータフロー分析のために/diet-assess-risk {name}の実行を検討してください。」
• 推奨 = REMOVE、作業量 >= Medium --> 「ガイド付きの実装のために/diet-remove {name} --prを使用します。」
• 推奨 = REMOVE、外部プロジェクト --> 「問題をファイルするために/diet-remove {name} --repo {owner/repo}を使用します。」

---

重要なルール

• dietの出力から始めます。 dietがすでに提供しているフィールドを再計算しないでください。
• 分類してからスコアリングします。 使用法分類(Phase 2)はすべてを変えます -- 6軸スコアリングの前に常にこれを行います。
• APIリークageはゲートであり、スペクトラムではありません。 エクスポートされた型がこのパッケージに依存している場合、すぐにこれにフラグを立ててください。
• 置換について具体的に述べます。 「stdlibを使用する」と言わないでください -- 特定の関数に名前を付け、バージョン要件に注記し、マイグレーションパターンを示します。
• IBNCパターンを尊重します。 has_blank_importがtrueでcall_site_countが0の場合、インポート自体が使用です。「未使用」と呼ばないでください。
• これはすべての言語で機能します。 diet JSONのecosystemフィールドが言語を示します。Phase 3aのエコシステム固有のコマンドを使用します。
• 一度に1つの依存関係です。 このスキルは単一依存関係の深い分析用です。バッチ評価の場合はループで実行します。