Menu
指定されたPR番号のDependabot PRを確認し、依存ライブラリのバージョンアップ内容をCHANGELOGとcontext7から取得して、コード修正が必要かを判定します。修正が必要な場合は修正を行い、pushまで実施します。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | check-dependabot |
| description | 指定されたPR番号のDependabot PRを確認し、依存ライブラリのバージョンアップ内容をCHANGELOGとcontext7から取得して、コード修正が必要かを判定します。修正が必要な場合は修正を行い、pushまで実施します。 |
| argument-hint | [pr-number] |
| hooks | {"Stop":[{"matcher":"","hooks":[{"type":"command","command":"node \"${CLAUDE_PLUGIN_ROOT}/scripts/stop-servers.mjs\""}]}]} |
Dependabot PRに対して、依存ライブラリのバージョンアップに伴う破壊的変更や注意点を確認し、既存コードへの影響有無を判定・修正するスキルです。Instructionsに従って、対象PRの情報取得・バージョン差分の分析・コード修正を行ってください。
!git fetch origin "$(gh repo view --json defaultBranchRef -q .defaultBranchRef.name)" >/dev/null 2>&1 || true
プリアンブル（
!インライン実行）に失敗しうるコマンドを置かないこと: プリアンブルのコマンドが失敗すると、セッションはモデル未起動のまま何も出力せず exit 0 で終了し、ワーカーが空振り実行を延々と繰り返す。プリアンブルには|| trueで非致命化したコマンドだけを置き、gh pr checkoutのような失敗しうるコマンドは本文のステップ0で実行する。
本スキル固有のリスク: 本スキルは claude-task-worker の check-dependabot ワーカー（dependencies ラベル）から自動起動され、ワーカーはスキルプロセスの同期完了を根拠に cc-triage-scope の付与や triage-pr への引き継ぎを進める。処理が未完のままターンを終えると、修正コミット未 push のまま triage-pr が古い差分でトリアージしたり、破壊的変更の調査未完でマージ判定に進む状態壊れが起きる。
以下を実行してPRブランチをcheckoutする。
gh pr checkout $ARGUMENTS
このコマンドが失敗した場合（典型例: fatal: '<branch>' is already used by worktree at ... — PRブランチが別のworktreeでcheckout中）は、後続のステップに進まず、エラー出力をそのまま含めて「判定: エラー」で結果報告を行い終了する。コード修正・push・ラベル操作は行わない（ブロッカー解消後のポーリングで自動的に再実行される）。
gh pr view $ARGUMENTS --json number,title,body,headRefName
取得したPRのタイトル・bodyから以下を抽出する。
Dependabotの標準タイトル形式: Bump <package> from <old-version> to <new-version>
複数パッケージの更新（grouped update）の場合は、PR bodyから各パッケージの更新情報を全て抽出する。
対象ライブラリの変更差分を、以下の優先順位で取得する。
Dependabot PRのbodyには多くの場合リリースノートとchangelogのサマリーが含まれるため、まずこれを確認する。
PR bodyに十分な情報がない、または破壊的変更の詳細確認が必要な場合は、GitHub上のCHANGELOGやReleasesを直接取得する。
tag_name は文字列であり、SemVerの大小関係と単純な文字列比較（>= / <=）の結果は一致しない（例: 文字列比較では "2.10.0" < "2.9.0" と判定される）。そのため範囲判定には sort -V（バージョンソート）を用いる。
# リポジトリの全releaseを取得
gh api repos/<owner>/<repo>/releases --jq '.[] | {tag_name, body}' > /tmp/releases.json
# from/to のtag_nameを "v" プレフィックス込みで正規化した上で、
# sort -V で範囲内（from超 〜 to以下）のtag_nameのみ抽出する例:
FROM="<from>"
TO="<to>"
# 各releaseのtag_nameがfromより大きくtoの範囲以下かを sort -V で判定
jq -r '.tag_name' /tmp/releases.json | while read -r TAG; do
NORM_TAG="${TAG#v}"
NORM_FROM="${FROM#v}"
NORM_TO="${TO#v}"
# NORM_FROM < NORM_TAG <= NORM_TO を sort -V で判定
LOWER=$(printf '%s\n%s\n' "$NORM_FROM" "$NORM_TAG" | sort -V | head -1)
UPPER=$(printf '%s\n%s\n' "$NORM_TAG" "$NORM_TO" | sort -V | head -1)
if [ "$LOWER" = "$NORM_FROM" ] && [ "$NORM_TAG" != "$NORM_FROM" ] && [ "$UPPER" = "$NORM_TAG" ]; then
echo "$TAG"
fi
done
# 対象tag_nameが判明したら、そのbodyのみをreleases.jsonから取り出す
jq --arg tag "<対象tag_name>" '.[] | select(.tag_name == $tag) | {tag_name, body}' /tmp/releases.json
# CHANGELOGファイルを直接取得
gh api repos/<owner>/<repo>/contents/CHANGELOG.md --jq '.content' | base64 -d
上記で十分な情報が得られない場合、または公式ドキュメントのマイグレーションガイドを確認したい場合は、context7 MCPを使用する。
# ライブラリIDの解決
mcp__plugin_claude-task-worker_context7__resolve-library-id
libraryName: "<ライブラリ名>"
# マイグレーションガイドや破壊的変更に関するドキュメント取得
mcp__plugin_claude-task-worker_context7__query-docs
context7CompatibleLibraryID: "<resolve-library-idで取得したID>"
topic: "migration breaking changes <from> to <to>"
取得した変更差分をもとに、以下の観点でリポジトリ内コードへの影響を確認する。
破壊的変更や非推奨APIがある場合、Grepツールで対象のシンボル・関数・設定名を検索し、使用箇所があるかを確認する。
PRのCIステータスを取得し、判定材料にする。
gh pr checks $ARGUMENTS
commit-push skillを用いてコミットとpushを行う追加のコミットは行わず、CIチェックが全てpassしていることを再確認した上で、以下のコマンドでPRをマージする。判定だけで終了せず、必ずマージコマンドを実行すること。
gh pr merge $ARGUMENTS --merge --delete-branch
マージコマンドが失敗した場合は、エラー内容を記録して報告する。CIがpassしていない場合はマージを実行せず、状況を報告する。
対象のバージョンはマージすることができない・するべきではないと判断する場合、PRをクローズする。例:
pwd処理結果として以下を報告する：
Re-analyze an existing GitHub Issue using its current title and body as input, refresh the implementation plan against the latest code state, and update the Issue in place. Use this when the user provides an Issue number (numeric, `#`-prefixed, or Issue URL) and wants to regenerate the code analysis via the explore-agent subagent. For reflecting comment-driven updates instead, use update-issue. For creating a brand-new Issue from a natural-language task description, use create-issue.
Create an implementation plan and a GitHub Issue based on the task description provided as an argument. Use this when the user supplies a natural-language task description (not an issue number) and wants a new implementation-ready Issue. If the input is an existing issue number, use create-issue-from-issue-number (re-analyze) or update-issue (reflect comments) instead.
GitHub Issueの確認事項に対して、コードベースやドキュメントを徹底的に調査し、根拠に基づいた回答を提供するスキル。Issueの最後のコメントに含まれる確認事項を調査・回答し、コメントに追記する。
ライブラリの情報を確認するためのスキル。Next.js、shadcn、その他のライブラリについて、適切なMCPサーバーを使用して最新のドキュメントと使用方法を取得します。
Create or update the Pencil (`.pen`) design for a UI implementation Issue before any code is written, then open a design-only PR. Takes the Issue number as argument, extracts the design requirements from the Issue description and comments, delegates `.pen` edits to the pencil-design-updater agent, exports snapshot PNGs, pushes them on the fixed `cc-ui-design-<Issue number>` branch, and opens a PR that references the Issue with `Refs #<N>` (never a closing keyword).
Execute tasks based on GitHub Issue content