# Wt Detail > コードベースを調査し、仕様の不明点をユーザーに確認してから詳細な実装プランを作り、そのプランを初期プロンプトとして worktree の Claude Code に渡して起動する。GitHub リポジトリではプラン確定後に issue を起票し、プラン全文を issue に残す。dev (本体 checkout) 側のセッションで使う。「/wt-detail <作業内容>」「調べてから worktree に投げて」のとき使う。 - Skill: `kawase1295/wt-detail` (Agent Skill) - Install (CLI): `npx skillmds@latest add kawase1295/wt-detail` - Raw SKILL.md: https://api.skillmd.com/api/skills/kawase1295/wt-detail/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: kawase1295 (https://skillmd.com/u/kawase1295) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/kawase1295/wt-detail --- # /wt-detail — プランを作ってから worktree に投げる 作業内容を dev 側で調査・計画し、実装プランを初期プロンプトとして worktree の Claude Code に渡す。**dev（本体 checkout）側で実行する**。worktree 側のセッションでこれを打たれたら、dev 側で実行するよう案内して止まる。 ## 手順 1. 引数が空なら、何を計画する worktree か質問する。 2. 引数が既存 issue（`#123`・番号のみ・issue URL。GitHub 連携時）なら、先に `gh issue view --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 --body-file ` で issue に残す。 - それ以外 → 起票する: タイトルは作業の体言止め要約、本文は `## 背景` + `## 受け入れ条件`（プランの目的・完了条件から起こす）+ `
実装プラン`（定型ヘッダを除いたプラン全文）`
`。`gh issue create --title <要約> --body-file ` で番号 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 --prompt-file ` を実行する。プランは平叙文で始める（先頭が `/` `!` `#` `@` なら `wt new` が worktree を作る前に die する）。名前は作業内容を要約した小文字 kebab-case（`[a-z0-9-]`）。GitHub 連携時は `-` を先頭に付けて 2〜3 語、番号なしなら 2〜4 語・30 字以内。`git branch --list 'worktree-*'` で衝突を確認し、衝突したら語を変える。ただし同じ issue 番号のブランチ（`worktree--*`）が既にあるときは別名を作らず、既存 worktree を報告して `wt open ` を案内して止まる。 9. 起動を報告し、issue URL（GitHub 連携時）、プランの要約（確定仕様・変更ファイル・手順の骨子）と、**確認せずに置いた前提**をユーザーに提示する。前提が違っていた場合は `/wt-ask` で worktree 側に訂正を送れる旨を添える。 ## エラー時 - 「herdr サーバなしでは Claude にプロンプトを渡せない」→ herdr の起動を促す。プランは scratchpad に、issue は GitHub に残っているので、herdr 起動後に同じコマンドを再実行すればよい（issue の再起票はしない）。