メニュー
commit 後に push、deploy、version bump、publish まで続けて依頼されたときに使う。commit 整理だけ、CI 修正、デプロイ基盤構築では使わない。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
コードベース全体、特定分野、ブランチ差分の改善候補を監査し、根拠付きで優先順位を付け、改善バックログとして残すときに使う。ユーザーが「$improve」「/improve」「コードベースを監査して」「改善候補を優先順位付きで出して」「改善バックログを作って」「このブランチで増えた問題を調べて」「改善バックログを再照合して」「リポジトリの次の方向性を考えて」と依頼した場合に使う。既知のバグ修正、直接の実装、通常のコードレビュー、設計済み作業の計画書作成、実装結果の受け入れ検証には使わない。
設計済みの作業を別エージェントへ渡すため、実装計画書や handoff プロンプトの作成を求められたときに使う。未確定要件の壁打ちや自分で実装する依頼では使わない。
他エージェントへのレビュー依頼、実装結果の受け入れ検証、レビュー結果の妥当性確認を求められたときに使う。PRレビューコメント対応や通常のセルフレビューでは使わない。
別のtmux paneで動いているAIエージェント（Claude Code / Codex / opencode等）へ指示やレビュー依頼を送信する、応答の完了を待って回収する、他paneのエージェントの出力や作業ログを読む、レビュー往復ループを回すときに使う。「%Nのpaneに送って」「隣のpaneのCodexにレビューを依頼して」「あのpaneが終わったら続きをやって」「右のpaneの作業を読んでまとめて」のような依頼で発動する。送る文面の作成自体（レビュー依頼文・handoffプロンプト）では使わず、agent-review-request / agent-handoff-plan に任せる。tmuxを介さないsubagent起動や並列化にも使わない。
Claude Code の /compact 前に、セッション状態の checkpoint を手動で保存するときに使う。「/compact-state」「compact 前に状態を保存して」「checkpoint を保存して」と依頼されたときに発動する。圧縮後の復旧作業、通常の進捗報告、plan 作成では使わない。
調査・監査・技術選定比較・性能検証・実装結果について、ユーザーが「結果をHTMLで読みやすく整理して」「HTMLの説明資料・レポートとして残して」のように、後から読み返せる静的HTML成果物を求めたときに使う。説明を補助する表、限定的な図解・定量グラフ・折りたたみ・定型指摘フィルタにも対応する。内容の調査・整理を伴わないHTML断片への変換、UI案や配色の比較モック、スライド、単体の探索的グラフ、任意JavaScriptを要する対話ツールには使わない。
SOC 職業分類に基づく
| name | release-flow |
| description | commit 後に push、deploy、version bump、publish まで続けて依頼されたときに使う。commit 整理だけ、CI 修正、デプロイ基盤構築では使わない。 |
「commit して deploy と push」「patch を上げて publish」という依頼を、 プロジェクトのリリース方式に合わせて preflight → 実行 → 結果検証まで一貫して行う。
最初にリリース方式を判別し、該当する 1 つのフローだけを実行する:
| 方式 | 判別材料 | フロー |
|---|---|---|
| Web deploy 型 | wrangler.toml / package.json に deploy script | commit → push → deploy → 検証 |
| タグ publish 型 | .github/workflows/publish.yml（v* タグ起動）+ package version | version bump → commit → タグ → push → workflow 監視 → 公開検証 |
| 個別型 | 上記以外（Cargo・独自 workflow・Makefile 等） | リポジトリの手順を調査し、ユーザーに確認してから実行 |
プロジェクトローカルに専用のリリーススキル（例: vde-layout の vde-layout-publish）が
存在する場合はそちらを優先する。このスキルは専用手順を持たないプロジェクト向けの汎用版。
git status で意図しない差分（依頼内容と無関係なファイル）を見つけたら、
進める前にユーザーに確認する。pnpm run build（deploy script に build が含まれる場合も、
push 前に失敗を検知するため単独で先に実行する）。lint / typecheck の script があれば併走git push origin HEADdeploy script を使う（例: pnpm run deploy）。
独自の deploy script がある場合に生の wrangler deploy を直接叩かない
（script 側の build 前処理や環境指定が抜けるため）package.json の現在バージョンと、レジストリの公開済みバージョンを確認する
（npm view <pkg> version dist-tags --json）。重複バージョンへの publish は失敗するpnpm run ci / lint + typecheck + test）と build を実行npm version <patch|指定> --no-git-tag-version。
version 以外の差分が混ざっていないか確認するBump version to <version> 形式でコミット → git tag v<version>git push origin HEAD && git push origin v<version>gh run list --workflow publish.yml --limit 5 で run を特定し、
gh run watch <run-id> で完了まで見届ける。失敗したら
gh run view <run-id> --log-failed で原因を取得して報告するnpm view <pkg> version が期待バージョンになったことを確認して報告するpublish.yml が無く、ローカルから直接 npm publish / cargo publish / deno publish する
運用のプロジェクトでは、公開コマンドの実行前にユーザーに一言確認する
（公開は取り消せない操作のため）。
wrangler.toml も publish.yml も無い場合は、README・Makefile・.github/workflows/ を読んで
リリース手順を特定し、「この手順で進める」という要約をユーザーに確認してから実行する。
特定できない場合は推測で公開系コマンドを実行しない。
完了時は次を報告する:
途中で止めた場合は、どのステップで何が失敗したか・リリースがどこまで進んだ状態か （例: 「タグは push 済みだが workflow が失敗、npm 未公開」）を必ず明示する。 中途半端な状態の放置が一番危険なので、復旧に必要な選択肢も添える。