メニュー
公開リポ（minorun365/agentcore-book）のDependabotアラート・PRを、読者のハンズオンを壊さない範囲で自動的に解消し続ける。/schedule での無人定期実行を想定
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | handle-dependabot |
| description | 公開リポ（minorun365/agentcore-book）のDependabotアラート・PRを、読者のハンズオンを壊さない範囲で自動的に解消し続ける。/schedule での無人定期実行を想定 |
| user-invocable | true |
| argument-hint | [dry-run] |
| model | sonnet |
『AgentCore＆Strands Agents本』読者向け公開リポジトリ minorun365/agentcore-book で、Dependabot が検出するセキュリティアラート・依存更新を、読者が書籍のハンズオン手順どおりに進めても支障が出ない範囲で自動的に解消し続けるためのスキル。/schedule での無人定期実行を前提に設計している。
💡 authoring リポ側にも同名
/handle-dependabotがあるが、あちらは 対話的に原稿影響まで見るスキル。こちらは 公開リポ専用・無人運用向けで役割が異なる。
「書籍どおりに読者が作業すれば自動でアップデートされるもの（＝原稿に登場しない依存のマイナー／パッチ更新）だけを自動で取り込む」。これが唯一の判断基準。
uv add foo==X した結果が pyproject.toml の直接依存ピン。ここは Dependabot が何を言ってきても勝手に変えない。原稿との乖離を絶対に作らない。uv.lock / package-lock.json に並ぶ**推移的依存（原稿に名前すら出てこない孫依存）**は、読者がロックを取り直せばどのみち動くバージョンに入れ替わる範囲。ここの semver 互換な更新（マイナー／パッチ）は無害なので、proactive に取り込んでよい。pyproject.toml / package.json に差分が出ない更新 ⇔ 原稿のピンが無傷 ⇔ 読者の手元で原稿どおり再現される ⇔ 取り込んでよい。逆に pyproject.toml / package.json が 1 行でも変わる更新は、原稿との整合が絡むので自動では絶対にやらない。dependabot.yml、リポジトリ Settings）を変更しない。Dependabot がセキュリティ更新PRを生成していなくても、アラートを直接ロックファイル修正で潰す。| 分類 | 条件 | 自動対応 |
|---|---|---|
| 🟢 即取り込み | uv.lock / package-lock.json だけが変わる更新（＝原稿に登場しない推移的依存の semver 互換更新）。Dependabot PR なら変更ファイルがロックファイルのみ。アラート修正なら uv lock --upgrade-package 後に pyproject.toml が無変更 | 無人で即マージ／即修正・コミット |
| 🟡 著者通知 | pyproject.toml / package.json に差分が出るもの全般。具体的には ①直接依存のバージョン制約／ピンが変わる ②直接依存のメジャー更新 ③脆弱性を直すのに原稿のピンを動かす必要がある | 自動マージ・自動コミットしない。GitHub Issue を作成/更新して @minorun365 にメンション通知し、判断を委ねる |
| 🔴 解消不能 | 制約・ピンをどう動かしても整合が取れない、互換バージョンの patched release が存在しない 等 | Issue で escalate。手は出さない |
迷ったら 🟡 に倒す。「原稿のピンを勝手に動かさない／読者のハンズオンを壊さない」が最優先で、セキュリティ対応の速さは二の次。コア依存（
strands-agents,bedrock-agentcore等）は通常pyproject.tomlの直接依存なので、ほぼ自動的に 🟡 になる。
引数に dry-run が指定された場合は、分類・サマリー報告までで止め、マージ・コミット・Issue 作成は行わない。
gh auth status
git -C ~/git/minorun365/agentcore-book remote get-url origin # agentcore-book であることを確認
cd ~/git/minorun365/agentcore-book && git switch main && git pull --ff-only
公開リポのローカル clone は ~/git/minorun365/agentcore-book/。/schedule のリモート実行で別の場所に checkout される場合は、そのリポルートを作業ディレクトリにする（git rev-parse --show-toplevel）。
オープンな Dependabot PR と未解決のセキュリティアラートの両方を取得する：
gh pr list --repo minorun365/agentcore-book --author "app/dependabot" --state open \
--json number,title,headRefName,files
gh api repos/minorun365/agentcore-book/dependabot/alerts \
--jq '[.[] | select(.state=="open")] | map({number, pkg: .dependency.package.name, ecosystem: .dependency.package.ecosystem, manifest: .dependency.manifest_path, severity: .security_advisory.severity, fixed_in: .security_vulnerability.first_patched_version.identifier})'
両方とも空なら「Dependabot 対応事項はありません」と報告して終了。
各 PR について diff 全文は読まない（uv.lock の diff は巨大なため）。Step 1 で取得した files フィールドだけで判定する：
uv.lock / package-lock.json のみ → 🟢pyproject.toml / package.json 内の直接依存が含まれる → PR タイトルの from X to Y でメジャー更新か・コア依存かを判定 → 🟡 or 🔴
gh pr diff <番号> --repo minorun365/agentcore-book -- '*.toml' 'package.json' のようにパスを絞る（lock ファイルは除外）Step 1 のアラートのうち、対応する Dependabot PR が存在しないものを自力で修正する。manifest のディレクトリへ移動し、対象パッケージだけをロックファイル上で安全バージョンに上げる：
pip（uv）の場合（例: manifest=chapter8/uv.lock, pkg=python-multipart, fixed_in=0.0.27）：
cd ~/git/minorun365/agentcore-book/chapter8
uv lock --upgrade-package python-multipart
git diff --stat
grep -A1 'name = "python-multipart"' uv.lock # patched version 以上になったか確認
git diff --stat の結果が uv.lock のみ → 🟢（次のステップでコミット）pyproject.toml も変わっている／uv lock がエラー／patched version に届かない → 制約を動かす必要あり → 🟡 or 🔴（Issue へ）npm の場合（例: manifest=chapter13/bookchecker/package.json, pkg=esbuild）：
公開リポでは package-lock.json が .gitignore で未追跡。よって npm 系の脆弱性は「ロックファイルだけ差し替えてコミット」ができない。脆弱性のあるパッケージが推移的依存（例: esbuild ← vite）なら、それを潰すには親の直接依存（vite 等）を package.json で上げるしかなく、これは package.json 変更＝🟡 に該当する。npm 系のアラートは自力修正せず、原則 🟡 として Issue 通知に回す（実態確認のため npm audit --json の結果だけは Issue に貼ってよい）。
pip（uv）で同じパッケージが複数の章の uv.lock に出ている場合は章ごとに繰り返す。
確定前のセルフチェック（1 つでも該当したら 🟢 を取り消して 🟡 に降格）：
pyproject.toml / package.json が含まれていないか？~/git/minorun365/agentcore-book-authoring/authoring/3_completed/ を grep -rn '<パッケージ名>'）。出ていたら原稿が固定しているバージョンなので 🟡。dry-run でなく上記チェックを通過したら：
gh pr merge <番号> --repo minorun365/agentcore-book --squash --delete-branch
cd ~/git/minorun365/agentcore-book
git add -A
git commit -m "⬆️ Dependabotアラート対応: <パッケージ名> をロックファイルで更新"
git push origin main
dry-run でなく、🟡・🔴 の項目があるとき：
gh issue list --repo minorun365/agentcore-book --state open \
--search "in:title 🤖 Dependabot 要レビュー" --json number,title
🤖 Dependabot 要レビュー: 自動マージできない依存更新があります）。@minorun365 をメンションし、各項目を箇条書きで：
from → to／影響する章／分類（🟡 or 🔴）／自動マージしなかった理由（メジャー更新・コア依存・制約変更が必要 等）/verify-reader-handson でハンズオン影響を確認 → 問題なければ手動マージ」「書籍本文にバージョン記載があるなら authoring リポ側で /update-lib-versions」）会話（または /schedule の実行ログ）に報告：
/schedule スキルで定期実行を登録できる（プロンプトに /handle-dependabot を指定）。無人実行時の挙動は固定：🟢 は自動マージ・コミット、🟡/🔴 は Issue 通知のみ。人間の判断が要る変更を勝手にマージすることはない。週次（毎週月曜 朝 など）が目安。
⚠️ このスキルファイル（
.claude/skills/handle-dependabot/SKILL.md）は公開リポで.gitignore除外されておりローカル限定。/scheduleのリモート実行で確実に使うには、(a) 公開リポの.gitignoreから.claude/skills/を外してコミットする、または (b) authoring リポ側に同等スキルを置いて運用する、のどちらかが必要。どちらにするかはみのるんと相談して決める（現状は (a)(b) どちらも未実施＝ローカル手動実行のみ動作）。
/verify-reader-handson 等で確認してから手動マージする。npm audit fix --force は使わない（破壊的変更を伴う）。--force が必要なら 🟡 として Issue へ。uv lock --upgrade（パッケージ無指定の全体更新）は使わない。脆弱性のあるパッケージだけを --upgrade-package で狙い撃ちし、巻き添えの更新を最小化する。pyproject.toml / package.json の直接依存（＝原稿のコードブロックに出てくるパッケージ）を上げる変更は、原稿と公開リポを揃えて更新する必要があるためこのスキルでは絶対に勝手にやらない。Issue で「authoring 側 /update-lib-versions で原稿のバージョン記載も更新 → 公開リポ側も追随」という対応案を提示し、@minorun365 の判断に委ねる。coding-style.md の対象外（自動生成物）。手書きの Python/TS は触らない。package-lock.json / uv.lock は「読者の手元と一致させる」方針。ロック更新コミット後、ファイルが消えていないことを確認する。