Menü
現在のリポジトリの変更をステージ・コミット・プッシュまで一気に行う。『コミットしてプッシュして』『vk-push』等の依頼時に使用。コミットメッセージは差分から自動生成する
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-push |
| description | 現在のリポジトリの変更をステージ・コミット・プッシュまで一気に行う。『コミットしてプッシュして』『vk-push』等の依頼時に使用。コミットメッセージは差分から自動生成する |
カレントリポジトリの変更を git add → git commit → git push まで一気通貫で行う。コミットメッセージは差分から自動生成し、毎回の指示を不要にする。
以下の表現が含まれる場合にこのスキルを使う:
PR 作成まで必要なら /vk-pr、issue から完了まで一気通貫なら /vk-kore を使う。このスキルは コミットとプッシュのみ を行い、PR 作成・CI 監視・changelog 更新は行わない。
$ARGUMENTS に渡せるのは コミットメッセージ か --direct フラグ のみ$ARGUMENTS にコミットメッセージが指定された場合は、それを（必要なら分類プレフィックスを補って）使う--direct フラグが含まれる場合は、main / master などの保護ブランチでも確認なしで直接 commit・push する（手順4参照）。--direct はコミットメッセージ本文に含めない--direct のみ。- で始まるトークンのうち --direct 以外（例: --force, -f, --no-verify, --amend など）が含まれていた場合は、git のオプションとして解釈せず、エラーとして報告して中断する（git push --force のような危険なオプション混入を防ぐため）--direct 以外の - 始まりトークンをコミットメッセージの一部として扱ったり、git コマンドにそのまま渡したりしない--direct は重複指定されても 1 回扱い。--direct とコミットメッセージの併用は許可（メッセージ指定かつ保護ブランチ直 push）git rev-parse --show-toplevel でリポジトリルートを確認する（git リポジトリでなければ中断して報告）git status --porcelain で変更の有無を確認する
git branch --show-current で現在のブランチ名を取得するgit status --porcelain と git diff --stat、必要に応じて git diff（未ステージ）/ git diff --cached（ステージ済み）で変更内容を理解する$ARGUMENTS でメッセージが指定されていればそれを使う（分類プレフィックスが無ければ後述の規約で補う）$VK_AGENTS_DIR/rules/change-title.md に準拠）:
[ 分類 ] 形式で付ける。分類は change-title.md の一覧（機能追加 / 不具合修正 / デザイン不具合修正 / セキュリティ修正 / 仕様変更 / 開発環境 / その他）から選ぶ。独自分類は禁止。迷ったら [ 仕様変更 ] か [ その他 ]git add -A で全変更をステージする（特定ファイルのみの指示があれば従う）git commit -m "$(cat <<'EOF'
[ 分類 ] 変更内容の要約
EOF
)"
main / master の場合は 事故防止のため、push 前にユーザーに確認する（保護ブランチへの直接 push は意図しない場合が多いため）。それ以外のブランチは確認不要で push する
$ARGUMENTS に --direct フラグが指定されている場合は、保護ブランチでも確認を省略して直接 push するgit pushgit push -u origin <ブランチ名>問題が起きた場合は、勝手な代替手段を取らず以下を確認し、解決できなければ出力を添えてユーザーにエスカレーションする。
git pull --rebase の要否を確認のうえ案内する。勝手に --force は使わない--no-verify で握りつぶさない