メニュー
GitHub issue から作業を開始するときに使用。実装の前段階（ブランチ作成・調査・計画・計画レビュー）までを行う。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
workspace/plan.md の完成後、実装着手前に使用。計画の影響範囲・不変条件・スコープの漏れを検証する。
コード変更を伴うタスク（機能追加・バグ修正・リファクタリング）の実装時に使用。実装からコミット作成まで自律的に行う（計画が要る変更は /start-issue へ）。
大きなサイクル完了後や定期メンテナンス時に使用。governance:check（決定的検査）を実行し、機械化できない意味的整合（コマンド直書き grep・npm ラッパー等価・メモリ整合）を検証して報告する（修正はしない）。
開発サイクル完了時（実装・レビュー・追加修正まで済んだ後）に使用。教訓の抽出・残タスクの振り分け・RETROSPECTIVE.md 更新を行う。
UI モード・状態遷移・ガード条件の追加・変更時、または計画レビュー時に使用。既存モードとの直交性・リセット経路・入力分岐・SPEC §8.6 整合を検証する。
worker スレッド・channel・フレーム drain・Tauri listener・スレッド/窓をまたぐ共有状態・フレーム内 live-read を追加/変更したとき、または async 関数を追加/変更したとき、あるいは計画レビュー時に使用。送信から適用までの窓での状態競合リスクを検証する。
| name | start-issue |
| description | GitHub issue から作業を開始するときに使用。実装の前段階（ブランチ作成・調査・計画・計画レビュー）までを行う。 |
| disable-model-invocation | true |
| argument-hint | <issue-number> |
| allowed-tools | ["Bash(git *)","Bash(gh *)","Read","Write","Grep","Glob","Skill"] |
Issue #$ARGUMENTS の作業を開始する。実装判断は自律的に行い、要求判断が必要な場合のみ確認する（後述）。
gh issue view $ARGUMENTS
issue の内容（タイトル・本文・ラベル・コメント）を把握し、要求が一意に解釈できるか判定する:
要求の曖昧さがある場合、最も影響の大きい1〜2点に絞って質問する。例:
回答を得てから Step 2 に進む。
以下を順に実行する:
git checkout main
git pull --ff-only
issue の内容から適切なブランチ名を決める:
feat/<短い説明>fix/<短い説明>chore/<短い説明>git checkout -b <branch-name>
workspace/research.md・workspace/plan.md・workspace/plan-review/（ディレクトリごと。/plan-review「Step 2 — 並列サブエージェントで検証」のスカウトと「Step 2b — 独立導出 + 差分（常に実施・盲点クラスの漏れ検出）」の成果物。ファイル名が毎回変わるため列挙せず、新鮮性は「上書き」ではなく /plan-review Step 2 が起動前に行う削除が保証する——上書きは書き手が落ちた回には起きない）が既に存在する場合は上書きする（前回の作業成果物）。このサイクルで書き直すファイルはここに列挙されたものだけである——列挙から漏れたものは前サイクルの内容のまま残り、次に読む人が今回の成果物と誤読する（workspace/measurement.md が #628 のまま取り残されている実例がある）。
SPEC.md、関連する CLAUDE.md、ソースコードを読み、issue の要求を分析する。
workspace/research.md に以下を出力:
SendInput/SetForegroundWindow/ShowWindow 等の入力・ウィンドウ系 API は部分的に非同期な場合がある。計画時に MSDN で同期性を確認し、技術的制約に記録する列挙の事実確認: 「関連コード」に挙げたファイル・関数が実在し、説明が正確かを grep で確認してから Step 4 へ進む。研究の前提誤りは plan へ伝播する——/plan-review「Step 2b」 の独立再導出が伝播後に拾うが、前提はここで正すのが最も安い。
外部ソースが根拠のときの追加確認（外部 issue・上流バグ・外部仕様を根本原因の根拠にする場合のみ発火。使わない issue では不要）: issue 本文冒頭の説明を確定事実とせず、timeline を最終 maintainer 回答まで辿って現在の結論（fixed / reverted / 未修正）を掴んでから前提として扱う。上流の記述とローカル実装（使用中バージョン・設定者→中間層→実 consumer の実行経路）が食い違うときは、どちらを採用したかを理由付きで research.md に記す。上の実在確認が内部前提を、/plan-review「Step 2b」 がコードベースを覆うのに対し、外部の事実だけはどの下流検査も再導出できない——ここで正さなければ後段で拾えない（#565。内部前提=能力・根本原因診断の裏取りは docs/development-principles.md「デバッグ・バグ修正」節）。
workspace/research.md の分析結果をもとに、workspace/plan.md に実装計画を作成する。
計画には以下を含める:
docs/development-principles.md の開発原則（KISS/DRY/YAGNI）と AGENTS.md「開発ワークフロー」の実装着手前（判定・要件確定・影響範囲・事前調査）に従うこと。
計画の内容に応じて該当する check スキルを実行し、計画の見落としを検出する。発見事項があれば計画を更新する。
/plan-review は常に実行する（サブエージェントで影響範囲・不変条件・スコープを並列検証）。AGENTS.md「条件別チェック（トリガー → 参照先）」表に従って選ぶ（トリガー→検査の写像の SSOT はその表。二重管理を避けるためここに再掲しない）。判定対象は計画が記述する設計上の操作であって、既存コードの grep 結果ではない。Step 5a の /plan-review が ①対称コードパス ②影響範囲の網羅性（呼び出し元 grep）③リソース管理（生成/破棄ペア・false に戻さない AtomicBool／unlisten の無い listen()／kill の無い子プロセス）④既存パターンとの整合 ⑤YAGNI を検証済みである（/plan-review「Step 2」の観点＋ /plan-review「Step 2b」の独立再導出）。5b でこれらを再実行しない——同一 plan.md への二度手間を避ける。plan-review の「要対処」を確認し、あれば workspace/plan.md を更新する。
ただしこの免除は、plan-review が「独立レビュー不成立」と報告したエントリには及ばない——そのレイヤーの ①〜⑤ は検証されていない。5b で自ら確認する（/plan-review の再実行は workspace/plan-review/ を作り直すため、届いていた他エントリの成果物も消える——当該レイヤーだけを 5b で見る方が安い）。不成立が残るならその事実と代替検証を workspace/plan.md 末尾の「セルフレビュー」セクションに記す（本ファイル末尾の引き渡し契約「レビュー済みの計画」が偽になるのを防ぐ）。
5b では plan-review が扱わない次の3観点だけを追加で確認し、問題があれば計画を修正する:
AGENTS.md「事前調査（レビュー未然防止）」）AtomicBool・Mutex・子プロセス等）・汎用インターフェース・暗黙の前提を導入する箇所について、より単純な代替がないか問い直す。「この操作が失敗したらどうなるか」を設計段階で書けているかplan-review の結果（要対処の解消）と 5b の3観点を、workspace/plan.md 末尾の「セルフレビュー」セクションに記録する。
セッション断絶・別マシン継続に備え、workspace/ を必ずコミットしてプッシュする。以下を順に実行する:
git add workspace/
git commit -m "chore: workspace 調査・計画 (issue #$ARGUMENTS)"
git push -u origin HEAD
最後に以下を報告:
/implement で実装に進めること引き渡し契約: ここで渡す workspace/plan.md は /plan-review を通したレビュー済みの計画である。/implement はこの前提で計画を読み、調査をやり直さない。計画を検証せずに渡してはならない——検証水準が入口によって変わると、/implement 側が前提を立てられなくなる。