warm

WARM

引数

生の引数：$ARGUMENTS

引数を差分比較するベースブランチとして解析します。空の場合は、デフォルトで main を使用します。

目標

このブランチがベースブランチから分岐して以降に取り込んだ依存関係（追加またはアップグレード）をWARMチェックに照らして評価し、それぞれに明確な判定を示します。クライアント側とサーバー側の依存関係を、あらゆる言語で対象にします。出力は、マージ前に新しい依存関係を維持するか、再検討するか、バージョンを固定するかパッチを適用するかをユーザーが判断するのに役立ちます。

WARM の意味は次のとおりです。

• Worth it?（導入する価値があるか）— 自分で書く約 20 行のコードで置き換えられませんか？ 午後のうちに自作できる依存関係なら、サプライチェーンのリスクを増やす価値はありません。
• Alive?（活発に開発されているか）— 最近のコミット、活発なメンテナンス、安定したリリースペースがあるかを確認します。何年も更新されていないパッケージはリスクになります。
• Right-sized?（規模は適切か）— 1 つの関数のためにライブラリ全体を取り込んでいませんか？ 実際に使う機能に応じて、依存関係の規模を見極めます。
• Maintained securely?（セキュリティが適切に維持されているか）— 既知の脆弱性（CVE／アドバイザリ）、未修正の問題、またはセキュリティ面で問題のある実績を持つメンテナーがいないか確認します。

対象は、自分で追加を選択した直接依存関係です。 4 つの質問は、自分が選んだ依存関係についての判断であり、その下位に引き込まれる推移的依存関係には適用されません。直接依存関係の追加を評価し、既知のアドバイザリがある場合に限り、Mの項目で推移的依存関係に言及してください。

手順

1. ブランチが取り込んだ依存関係を特定する

git diff --name-status <base>...HEAD（三点リーダー — ベースから分岐して以降のこのブランチの変更）を実行し、変更された依存関係マニフェストを特定します。これらは直接依存関係を宣言するファイルで、すべてのエコシステムに存在します。

• JS/TS（クライアント側とサーバー側）：package.json
• PHP：composer.json
• Python：requirements*.txt、pyproject.toml、Pipfile、setup.py、setup.cfg
• Ruby：Gemfile、*.gemspec
• Go：go.mod
• Rust：Cargo.toml
• Java/Kotlin：pom.xml、build.gradle、build.gradle.kts
• .NET：*.csproj、Directory.Packages.props、packages.config
• Elixir：mix.exs
• Dart/Flutter：pubspec.yaml
• Swift：Package.swift

この一覧に限定せず、変更されたファイルが別のエコシステムのマニフェストであることが明らかな場合は、マニフェストとして扱ってください。

変更された各マニフェストについて、git diff <base>...HEAD -- <manifest> を実行し、追加された依存関係の行（およびバージョンの更新）を抽出します。ロックファイルの差分（package-lock.json、composer.lock、pnpm-lock.yaml、go.sum、Cargo.lock など）は、解決されたバージョンの確認と、アドバイザリのある推移的依存関係の特定にのみ使用してください。評価対象の依存関係を選ぶための情報源としては使用しないでください。

対象範囲：

• 新しい直接依存関係 → WARM の全項目を評価します。
• 既存の直接依存関係のバージョンアップグレード → AとMのみを評価します（導入時に Worth-it と Right-sized はすでに判断済みです）。バージョンの差分を記載します。
• 削除された依存関係 → 無視します。

マニフェストに変更がない場合は、次をそのまま出力します。

✅ No dependencies added or upgraded on this branch.

…そして終了します。

2. 各依存関係の事実を集める

各項目に正直に回答するために必要な情報を調べます。情報源は、以下の優先順位で確認します。

• W（価値があるか）：ブランチがその依存関係を実際にどう使っているかを確認し（インポート／require／使用箇所をGrepで調べます）、依存する範囲を評価します。1つのコンポーネントで使う日付フォーマッターと、あらゆる場所で使うHTTPクライアントでは、評価が異なります。
• A（現役か）：レジストリ／リポジトリで、最終リリース日と最近のコミット状況を確認します。npm view <pkg> time.modifiedを使うか、レジストリまたはリポジトリのページをWebFetchします。最新リリースの日付と、リポジトリがアーカイブ済みかどうかを記録します。
• R（規模が適切か）：依存関係の規模（サブ依存関係、インストールサイズ、APIの広さ）を、ブランチが使用する範囲と比較します。1つのヘルパーを呼び出すために40個の依存関係を持つフレームワークを取り込むのは、規模が適切ではありません。
• M（安全に保守されているか）：既知のアドバイザリを確認します。利用できる場合はエコシステムのツール（npm audit、composer audit、pip-audit）を優先し、それ以外の場合はパッケージ名と「CVE」／「advisory」を組み合わせてWebSearchし、アドバイザリデータベースを確認します。解決済みのバージョンと、修正済みバージョンがあるかどうかを報告します。

**誠実さのルール：**確認できない場合（ネットワークが使えない、レジストリに接続できない、パッケージが特定できないなど）は、確認した内容を記載し、その項目をunknownとします。リリース日、バージョン、CVEを捏造してはいけません。

3. 評価して判断する

依存関係ごとに各項目を次のように評価します。

• ✅ — この観点では問題ありません
• ⚠️ — 再確認する価値のある懸念があります
• ❌ — 実際の問題があります
• ? — 確認できませんでした

次に、評価に基づく1語の判定を示します。

• Keep — ❌はなく、⚠️は軽微なものに限られます。
• Reconsider — WまたはRに❌があります（この依存関係、またはその全機能が必要ない可能性があります）。
• Patch/Pin — Mのみに❌があります（依存関係自体は妥当ですが、セキュリティ上の問題があるため、修正版へアップグレードするか、バージョンを固定します）。
• Replace — Aに❌があります（保守されていない）、または❌が複数あります。

4. レポートを出力する

懸念の大きい順に依存関係を並べます。まず❌の判定、次に⚠️、最後に問題のないKeepを記載します。以下の形式を厳守してください。

## `dayjs` — added to package.json (client)

- ✅ **Worth it** — date parsing used across 6 components; non-trivial to hand-roll correctly
- ✅ **Alive** — last release 2 months ago, active repo
- ✅ **Right-sized** — 2KB, zero dependencies, tree-shakeable
- ✅ **Maintained securely** — no known advisories for 1.11.x

**Verdict: Keep**

## `left-pad` — added to package.json (client)

- ❌ **Worth it** — single use, pads a string; ~5 lines of your own code replaces it
- ⚠️ **Alive** — last release 4 years ago
- ✅ **Right-sized** — tiny, no sub-dependencies
- ✅ **Maintained securely** — no known advisories

**Verdict: Reconsider** — inline it rather than take the supply-chain surface.

## `guzzlehttp/guzzle` — upgraded 7.4.0 → 7.4.5 in composer.json (server)

- ✅ **Alive** — actively maintained
- ❌ **Maintained securely** — 7.4.0 affected by GHSA-xxxx (cookie leak); 7.4.5 fixes it

**Verdict: Patch/Pin** — the upgrade resolves the advisory; keep it.

最後に、1行の要約を記載します：N dependencies evaluated — X keep, Y reconsider, Z replace/patch.

ルール

• **ブランチが取り込むものだけを評価します。**既存の依存関係ツリー全体を監査せず、ベースブランチからの追加と更新のみを対象にします。
• **直接依存関係はWARMの全項目を評価します。**推移的パッケージは、既知のアドバイザリがある場合に限り、Mの項目でのみ扱います。
• **クライアント側とサーバー側の両方を対象にします。**各依存関係がどちら側にあり、どのマニフェストに記載されているかを明記して、ユーザーが場所を特定できるようにします。
• **言語を問いません。**どのエコシステムのマニフェストも同じように扱います。異なる言語に慣れているかどうかを理由に依存関係を省略してはいけません。
• **事実を捏造しません。**リリース日、バージョン、アドバイザリは実際に調査して確認します。確認できない場合は?を付け、何を確認したかを記載します。
• **懸念は箇条書き1つにつき1つです。**WARMの各項目は1行ずつ記載し、2つの調査結果をまとめてはいけません。
• 具体的かつ定量的に記載します。「最終リリースは4年前」「推移的な依存関係を40個取り込む」「GHSA-xxxxは7.4.5で修正済み」のように記載します。「古そう」「問題があるかもしれない」のような表現は使いません。
• 判定は評価に従います。❌をKeepにしたり、問題のない依存関係をReconsiderにしたりしてはいけません。判定を明確に示します。
• **前置きは不要です。**最初の## 依存関係の見出し（または依存関係がない旨の行）から始めます。「WARMチェックの結果です」のような前置きは不要です。
• **ファイルを変更してはいけません。**このスキルは評価と報告のみを行います。依存関係の削除、マニフェストの編集、インストールの実行は行いません。