القائمة
commit 後に push、deploy、version bump、publish まで続けて依頼されたときに使う。commit 整理だけ、CI 修正、デプロイ基盤構築では使わない。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
コードベース全体、特定分野、ブランチ差分の改善候補を監査し、根拠付きで優先順位を付け、改善バックログとして残すときに使う。ユーザーが「$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を要する対話ツールには使わない。
| 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 未公開」）を必ず明示する。 中途半端な状態の放置が一番危険なので、復旧に必要な選択肢も添える。