Wt Detail

/wt-detail — プランを作ってから worktree に投げる

作業内容を dev 側で調査・計画し、実装プランを初期プロンプトとして worktree の Claude Code に渡す。dev（本体 checkout）側で実行する。worktree 側のセッションでこれを打たれたら、dev 側で実行するよう案内して止まる。

手順

1. 引数が空なら、何を計画する worktree か質問する。

2. 引数が既存 issue（#123・番号のみ・issue URL。GitHub 連携時）なら、先に gh issue view <N> --json number,title,body,state で取得する。OPEN でなければ報告して止まる。issue 本文が作業内容になる。本文が複数の独立タスクのチェックリストになっている（または既に ## 子タスク に分解済みの）issue は 1 つの worktree に詰め込まず、/wt-split を案内して止まる。

3. 調査は dev 側の自分が行う（worktree 側にやり直させない）。作業内容に関連するファイル・既存パターン・影響範囲を読む。規模が大きければ Explore subagent に投げる。

4. 仕様の不明点をユーザーに質問する（省略禁止）。調査で埋まらなかった判断を推測で埋めてはいけない。AskUserQuestion で聞き、回答を得てから次へ進む。worktree に投げた後だと、ユーザーが食い違いに気づくのは実装が終わってからになる。

   聞く	聞かない
   答えが変わるとプランの中身が変わる判断 — 対象範囲（どの画面・どの経路・既存改修か新規追加か）、挙動の選択（エラー時の扱い・既定値・後方互換を保つか）、取り込み条件（テストをどこまで書くか・破壊的変更の可否）	コードを読めば判る事実（既存パターン・ファイル配置・命名規約）、慣例的でどちらを選んでも結果が変わらないもの

   質問は 1 回にまとめる（最大 4 件）。各質問には推奨案を先頭に置き、なぜ推奨なのかを添える。質問が 1 件も無いと判断したときだけ質問を飛ばせるが、その場合も手順 9 で「確認せずに置いた前提」を必ず報告する。

5. プランを作成する。フォーマット:

   • 目的（何を・なぜ）
   • 確定仕様（手順 4 でユーザーが選んだ内容をそのまま書く）と、確認せずに置いた前提
   • 変更ファイルと具体的な変更内容（ファイルパスは絶対パスで書く。worktree 側から見えるように、本体でなく worktree 内のパスになる点に注意 — 相対パス + 「repo root 基準」と明記する形でもよい）
   • 実装手順
   • テスト方法（実行コマンド）
   • 完了条件

6. GitHub 連携（gh repo view --json nameWithOwner が成功する repo）なら issue を用意する。このとき本体 checkout の現在ブランチ（= worktree の base）が default branch と異なるなら、PR の base（default branch）とずれて無関係なコミットが PR に混ざるため、その旨を伝えて続行してよいか確認する:

   • 引数が既存 issue（手順 2 で取得済み）→ 起票せず、プラン全文（手順 7 の定型ヘッダは除く）を gh issue comment <N> --body-file <path> で issue に残す。
   • それ以外 → 起票する: タイトルは作業の体言止め要約、本文は ## 背景 + ## 受け入れ条件（プランの目的・完了条件から起こす）+ <details><summary>実装プラン</summary>（定型ヘッダを除いたプラン全文）</details>。gh issue create --title <要約> --body-file <path> で番号 N を得る。

7. プラン冒頭に定型ヘッダを付ける:

   あなたは worktree 内の実装担当。以下は dev 側で調査済みの実装プラン。追加調査より実装を優先すること。プランに書かれていない判断が必要になったら勝手に決めず、プランを書いた dev 側セッションに /wt-ask で聞くこと（宛先は wt peers の role=dev 行の name）。実装が終わったら変更をコミットし、/wt-review でレビュー用ページを生成してユーザーのレビューを待つこと。承認を得てから /wt-merge でこのブランチを本体に取り込み、/wt-clean で worktree を片付けること。承認前にマージしない。プランにマージまで行う旨が含まれていても、このレビューゲートが優先される。

   GitHub 連携時は「承認を得てから…」「承認前にマージしない。」の 2 文を次に差し替え（N は実番号に置換）、ヘッダ直後に「この作業は issue #N に対応する。」の行を足す:

   承認を得てから /wt-merge で PR を作成すること（ブランチが push され、PR 本文の Fixes #N でこの issue が閉じる）。PR がマージされたら /wt-clean で worktree を片付けること。承認前に PR を作らない。

8. scratchpad にプランをファイルとして書き、worktree 名を生成して wt new <name> --prompt-file <planfile> を実行する。プランは平叙文で始める（先頭が / ! # @ なら wt new が worktree を作る前に die する）。名前は作業内容を要約した小文字 kebab-case（[a-z0-9-]）。GitHub 連携時は <issue番号>- を先頭に付けて 2〜3 語、番号なしなら 2〜4 語・30 字以内。git branch --list 'worktree-*' で衝突を確認し、衝突したら語を変える。ただし同じ issue 番号のブランチ（worktree-<N>-*）が既にあるときは別名を作らず、既存 worktree を報告して wt open <task> を案内して止まる。

9. 起動を報告し、issue URL（GitHub 連携時）、プランの要約（確定仕様・変更ファイル・手順の骨子）と、確認せずに置いた前提をユーザーに提示する。前提が違っていた場合は /wt-ask で worktree 側に訂正を送れる旨を添える。

エラー時

• 「herdr サーバなしでは Claude にプロンプトを渡せない」→ herdr の起動を促す。プランは scratchpad に、issue は GitHub に残っているので、herdr 起動後に同じコマンドを再実行すればよい（issue の再起票はしない）。