Menü
設計済みの作業を別エージェントへ渡すため、実装計画書や handoff プロンプトの作成を求められたときに使う。未確定要件の壁打ちや自分で実装する依頼では使わない。
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
コードベース全体、特定分野、ブランチ差分の改善候補を監査し、根拠付きで優先順位を付け、改善バックログとして残すときに使う。ユーザーが「$improve」「/improve」「コードベースを監査して」「改善候補を優先順位付きで出して」「改善バックログを作って」「このブランチで増えた問題を調べて」「改善バックログを再照合して」「リポジトリの次の方向性を考えて」と依頼した場合に使う。既知のバグ修正、直接の実装、通常のコードレビュー、設計済み作業の計画書作成、実装結果の受け入れ検証には使わない。
他エージェントへのレビュー依頼、実装結果の受け入れ検証、レビュー結果の妥当性確認を求められたときに使う。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を要する対話ツールには使わない。
UI改善案、配色案、レイアウト案、情報密度の異なる案を、複数の静的HTMLモックとして比較・選択したいときに使う。「UI案をHTMLで比較して」「見た目を複数案出して」のような自然言語でも適用する。調査結果や技術比較を説明資料として残す依頼、単一案の実装、挙動・product logicだけの変更には使わない。
| name | agent-handoff-plan |
| description | 設計済みの作業を別エージェントへ渡すため、実装計画書や handoff プロンプトの作成を求められたときに使う。未確定要件の壁打ちや自分で実装する依頼では使わない。 |
生成したハンドオフプロンプトを別のtmux paneのエージェントへ送信する場合、輸送手順は tmux-agent-bridge スキルに従う。
設計と方針が固まった作業を、別の実装エージェントが単独で完遂できる形に落とし込むワークフロー。 成果物は依頼種別で分岐する。
このスキルの品質基準は「実装エージェントが渡された成果物だけを読んで、途中でユーザーに質問せずに完了できるか」。 判断の余地が残っている箇所は、成果物を書く前にユーザーに確認して確定させる。
実装完了後の検証と差し戻しは agent-review-request スキルの領域なので、
ハンドオフ用の成果物を渡した時点でこのスキルの仕事は終わり。
依頼文から出力モードを決める。
プロンプト単体モード:
このモードではファイルを作成しない。 計画書の作成と計画書パスを前提にしたプロンプト生成は行わない。
文書作成モード:
このモードでは Markdown ファイルを作成する。 DoD のない計画書、仕様書、設計書は未完成として扱う。
モードが判断できない場合は、ファイル作成を伴わないプロンプト単体モードとして扱う。 ただし、ユーザーの依頼から文書化の必要性が読み取れる場合は、作成前に確認する。
文書作成モードの場合だけ実行する。 プロンプト単体モードではこのステップをスキップする。
置き場所と命名: プロジェクトに文書ファイルの置き場所の規約があればそれに従う
（例: docs/plans/、docs/superpowers/plans/）。なければそのリポジトリの docs 以下に置く。
同日に複数作る場合は -plan-02 のように連番を付ける。
構成: 計画書、仕様書、設計書には次のセクションを必ず含める。
# <タイトル>
## 背景と目的
（なぜこの変更をするか。現状の問題点）
## 確定済みの設計判断
（採用案とその理由。検討して不採用にした案があれば理由付きで明記。
実装エージェントが「こっちの方が良いのでは」と迷わないようにする）
## 実装フェーズ
（Phase 1, 2, ... に分解。各フェーズに:
- 対象ファイルと変更内容（ファイルパスは実在確認済みのものを書く）
- そのフェーズの完了条件）
## 参照物
（HTML モック、スクリーンショット、関連ドキュメントのローカルパス。
モックが仕様源になる場合は「このモックが唯一の仕様源」と明記し、
モック内のどの要素がどのコードやトークンに対応するかを書く）
## DoD（Definition of Done）
- [ ] 機能完了条件（測定可能な形で列挙）
- [ ] テスト完了条件（実行するコマンドと期待結果）
- [ ] 運用反映条件（lint / typecheck / build の通過、必要ならドキュメント更新）
## やらないこと
（スコープ外を明示。実装エージェントの善意の拡大解釈を防ぐ）
文書作成モードの場合だけ実行する。 プロンプト単体モードではこのステップをスキップする。
書き終えたら渡す前に一度見直す。前半で挙げた基準（質問なしで完了できるか・現実のコードと一致しているか）に加えて、次を確認する。
実装エージェントの入力欄にそのまま貼れるプロンプトをコードブロックで出力する。
プロンプト単体モードでは、文書ファイルを参照させず、必要な情報をプロンプト本文に直接含める。 テンプレート:
対象リポジトリ: <絶対パス>
以下の内容に従って実装してください。
AGENTS.md / CLAUDE.md のルールに従ってください。
## 背景と目的
<なぜこの変更をするか。現状の問題点>
## 確定済みの設計判断
<採用案、理由、変更してはいけない判断>
## 対象範囲
<変更対象のファイル、モジュール、画面、機能>
## 実装手順
<実装フェーズまたは具体的な作業順>
## 完了条件
<機能として満たすべき測定可能な条件>
## 検証
<実行するコマンドと期待結果>
## 停止条件
<矛盾、不明点、想定外の差分など、自己判断せず停止する条件>
## やらないこと
<スコープ外>
文書作成モードでは、作成した文書を読む前提のプロンプトにする。 テンプレート:
対象リポジトリ: <絶対パス>
<文書ファイルの絶対パス> を読んで、この文書に従って実装してください。
AGENTS.md / CLAUDE.md のルールに従ってください。
- 文書ファイルの「確定済みの設計判断」は変更しない。実装中に矛盾や不明点を見つけた場合は、
自分で判断せず、その箇所を報告して停止する
- 「やらないこと」に書かれた範囲には手を出さない
- 完了したら DoD チェックリストの各項目について、実行したコマンドと結果を添えて報告する
agent-review-request スキルで
受け入れ検証を行う（文書ファイルがある場合は、そのパスを検証の入力として渡す）。