Menü
bot（Dependabot 等）が自動作成したプルリクエストを一覧化し、patch は自動マージ提案、minor/major は確認の上でマージする
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
vk-orchestrator をリリースする。同梱する vk-terminals / vk-agents を最新にそろえてから、バージョン付与・CHANGELOG 確定・タグ push まで一気通貫で行う。「orchestrator をリリース」「vk-orchestrator-release」で起動。
メイン Claude がディレクター（司）として振る舞う。GitHub issue管理、和田（エンジニア）への実装指示、植草（UX）との連携・確認を統括する。
e2eテスト・UIテスト担当（麗美）をサブエージェントとして起動する。PRに対してPlaywrightでブラウザ操作テストを実施する。コードレビューはスコープ外。
GitHub issue の URL を受け取り、司（staff-director）が内容を分析→適切なメンバーに委任→完了確認→報告まで一貫して行う
VK Orchestrator の初回セットアップを対話で行う。doctor で不足項目を検知し、モード選択（ローカル/GitHub）→ 依存順のヒアリング → 3 ファイル（A/B/C）への保存 →（GitHub モード時のみ）ラベル登録 → 再 doctor で確認まで伴走する。
リードエンジニア（安藤保）をサブエージェントとして起動する。コード品質・レビューの最終責任者。設計・可読性・保守性・パフォーマンス・セキュリティの全般をレビュー。「安藤さん」「保さん」で呼び出し可能。
| name | vk-bot-pr |
| description | bot（Dependabot 等）が自動作成したプルリクエストを一覧化し、patch は自動マージ提案、minor/major は確認の上でマージする |
前提条件（硬ゲート）: このスキルは、対象リポジトリの owner が許可リスト
org.allowed_owners（~/.vk-agents/config.json）に含まれる場合のみ使用できます。判定手順はrules/repository-access.mdを参照（許可リスト未設定時は確認のうえ続行可）。
Dependabot などの bot が自動作成したプルリクエスト（build(deps) / build(deps-dev) / chore(deps) など）を一覧化し、安全な patch アップデートは自動マージを提案、minor / major はユーザー確認のうえマージする。
以下の表現を含む場合に使う:
build(deps-dev) の PR を処理して」$ARGUMENTS にリポジトリの PR 一覧 URL（例: https://github.com/vektor-inc/lightning/pulls）を 1 つ指定する$ARGUMENTS から URL を取得するowner/name を抽出する（例: vektor-inc/lightning）
https://github.com/<owner>/<name>/pulls または https://github.com/<owner>/<name>rules/repository-access.md のゲート判定にかける（硬ゲート）。許可リストに含まれない owner なら処理を中断する（許可リスト未設定時は確認のうえ続行可）gh コマンドで open 状態の bot 作成 PR を取得する:
gh pr list \
--repo <owner>/<name> \
--state open \
--json number,title,author,headRefName,baseRefName,mergeable,mergeStateStatus,statusCheckRollup,url \
--limit 50
取得後、以下で bot PR をフィルタする:
author.login が以下のいずれかと一致する:
dependabot[bot]renovate[bot]github-actions[bot]title が build(deps) / build(deps-dev) / chore(deps) / chore(deps-dev) のいずれかで始まるbot PR が 0 件ならその旨を報告して終了する。
各 PR のタイトルからバージョン更新レベルを判定する。Dependabot のタイトル形式:
build(deps): bump <package> from <old> to <new>
build(deps-dev): bump <package> from <old> to <new>
<old> と <new> を semver として比較する:
1.2.3 → 1.2.4（パッチ番号のみ変化）1.2.3 → 1.3.0（マイナー番号が変化）1.2.3 → 2.0.0（メジャー番号が変化）複数パッケージをまとめた PR は、含まれる更新の最大レベルを採用する（一つでも major があれば major）。
取得した PR を以下の形式で表示する:
#<番号> [<レベル>] <タイトル>
CI: <成功/失敗/進行中> Mergeable: <yes/no/conflict>
URL: <PR URL>
ソート順: patch を先頭、次に minor、最後に major / unknown。
patch レベルの PR のうち、以下を全て満たすものを「自動マージ候補」としてユーザーに提示する:
mergeable が MERGEABLEstatusCheckRollup の全チェックが SUCCESS（CI がグリーン）mergeStateStatus が CLEAN提示形式:
以下の patch アップデート PR は CI もグリーンで安全にマージできます。マージしてよいですか？
- #123 build(deps-dev): bump eslint from 8.50.0 to 8.50.1
- #124 build(deps): bump axios from 1.6.2 to 1.6.3
ユーザーが承認した場合のみ 以下を実行する:
gh pr merge <番号> --repo <owner>/<name> --squash --delete-branch
マージ方式（--squash / --merge / --rebase）はリポジトリのデフォルトに合わせる。判断できなければ --squash を使う。
CI が失敗している、または mergeable が CONFLICTING の PR は、ユーザーに丸投げせず 必ず原因を調査し、可能な範囲で調整してから マージ判断へ進む。
重要: 調整アクション（rebase 指示・rerun・ローカル修正など）を実行したら、必ず CI 完了まで監視し、結果を見て次を判断する。「アクションを投げて報告して終わり」は禁止。 CI がグリーンになるか、6-5 の打ち切り条件に該当してユーザーへ escalate のいずれかに到達するまで、このスキルは終わらせない。
失敗チェック一覧を取得する:
gh pr checks <番号> --repo <owner>/<name>
失敗ジョブのログを取得し、原因を特定する:
gh run view <run-id> --repo <owner>/<name> --log-failed
# 出力が長く失敗箇所が埋もれる場合は、ジョブのステップ一覧から失敗ステップを特定する
gh run view --job <job-id> --repo <owner>/<name>
原因別の対応方針:
gh pr comment <番号> --repo <owner>/<name> --body "@dependabot rebase"
gh run rerun <run-id> --repo <owner>/<name> --failed
いずれの対応を取った場合も、必ず 6-4 (CI 監視ループ) に進む。
mergeable が CONFLICTING の場合、Dependabot 製 PR は原則コメントでリベースさせる:
gh pr comment <番号> --repo <owner>/<name> --body "@dependabot rebase"
実行後は 6-4 (CI 監視ループ) に進む。Dependabot 以外、または上記でも解消しないコンフリクトは 6-3 に従ってローカルで解消する。
リポジトリのローカルクローンが手元にある前提で、対象 PR を checkout して調整する:
gh pr checkout <番号> --repo <owner>/<name>
git fetch origin <base-branch>
git merge origin/<base-branch> # またはリポジトリ規約に応じて rebase
# コンフリクト解消（lockfile は base 側を採用し、パッケージマネージャで再生成するのが基本）
git push
package-lock.json / composer.lock / yarn.lock など）は手で編集せず、npm install / composer update --lock などで再生成するpush が完了したら 6-4 (CI 監視ループ) に進む。
6-1 〜 6-3 のいずれかのアクションを実行したら、必ずこのステップを実行する。アクション直後に報告して終わらせない。
再実行される CI run を特定する（rebase や push なら新しい run、rerun なら同じ run-id）。少し待ってから:
gh pr checks <番号> --repo <owner>/<name>
gh run list --repo <owner>/<name> --branch <headRefName> --limit 3 \
--json databaseId,status,conclusion,workflowName,createdAt
で新しい run の id を取得する。
CI 完了まで監視する。gh run watch でも良いし、定期的にポーリングしても良い:
gh run watch <run-id> --repo <owner>/<name> --exit-status
run_in_background で監視しつつ他の PR の作業を進めても良いCI 完了後、再評価する:
gh pr view <番号> --repo <owner>/<name> \
--json mergeable,mergeStateStatus,statusCheckRollup
結果に応じて分岐する:
MERGEABLE & CLEAN → 6-6 (マージ判断へ復帰)CI が再度失敗した場合、以下を順に試す。同じ戦略を繰り返さない:
gh run rerun <run-id> --failed --repo <owner>/<name> で再実行 → 6-4 に戻る@dependabot rebase を再投稿（前回から 24h 以上経っているか、base に新しい変更がある場合のみ意味あり） → 6-4 に戻る打ち切り条件（いずれかに該当したら escalate）:
escalate 時は以下をまとめてユーザーに報告し、指示を仰ぐ:
CI グリーン・MERGEABLE・CLEAN になった PR は:
CI がグリーンかつ MERGEABLE の minor / major / unknown レベル PR は、破壊的変更のリスクがあるため 必ずユーザー承認を経てマージする。
ただし PR ごとに個別質問せず、該当する CI グリーン PR をまとめて 1 回の確認で承認を得る（patch と同じスタイル）。
提示形式:
以下の minor / major アップデート PR は CI グリーンです。マージしてよいですか？
- #1325 [minor] build(deps-dev): bump simple-git from 3.33.0 to 3.36.0
用途: ビルドスクリプト等で使う dev 依存。変更点: <changelog 要約 or リンク>
- #1324 [minor] build(deps-dev): bump @babel/plugin-transform-modules-systemjs from 7.24.1 to 7.29.4
用途: Babel ビルドプラグイン (devDependency)。変更点: <changelog 要約 or リンク>
各 PR に、ユーザー判断に必要な情報を簡潔に添える:
質問の作法: 「どれをマージしますか？」と PR を選ばせる multi-select ではなく、「全部マージしてよいか？」の単一確認を基本とする。ユーザーが「#X だけ」「#Y は保留」などと部分指示した場合は、その指示通りに動く。
ユーザーが承認した場合のみ 各 PR を順次マージする:
gh pr merge <番号> --repo <owner>/<name> --squash --delete-branch
最後に以下を報告する:
gh コマンドが利用できない場合は事前にユーザーへインストールを促す