ousiass/impl-wt

impl-wt

impl の worktree 隔離版。メインの作業ツリーを汚さずに実装を行う。

前提条件

• Claude Code 環境
• git, gh CLI

引数

• Issue 番号 (例: /impl-wt #123): GitHub Issue から要件を取得
• Issue URL (例: /impl-wt https://github.com/owner/repo/issues/123): 同上
• テキスト (例: /impl-wt ユーザー認証機能を追加): テキストを要件として扱う
• 引数なし: ユーザーに要件をヒアリング

禁止行動（最重要）

以下に該当した場合はそのフェーズをやり直す。コンテキスト節約や軽微変更を理由にした省略は認めない。

• 「あとで実装」「TODO で残す」「別 PR で対応」を理由にサブステップ（2-1〜2-6）を省く
• ユーザーへの宣言なしにフェーズ・サブステップを飛ばす（サイレントスキップ）
• テストを未実装・ダミー（expect(true).toBe(true) 等）のままコミットする
• review エージェントを呼ばずに自己レビューで済ませる
• lint/format を試行せずスキップする（実行 → 該当設定なしを確認した場合のみスキップ可）

スコープを縮小したい場合は、フェーズの省略ではなくフェーズ1のスコープ分割からやり直し、ユーザーに確認する。

フェーズ1: 要件分析とスコープ分割

1. 引数から要件を取得する
   • Issue: gh issue view で本文・コメントを読み取る
   • テキスト: そのまま要件として扱う
   • 引数なし: ユーザーにヒアリング
2. 仕様書を確認する
   • CLAUDE.md に仕様書の格納場所が記載されていればそれに従う
   • 記載がなければ Glob で探す（**/SPEC.md, **/spec/**, docs/** 等を幅広く検索）
   • Issue 本文にリンクされたドキュメントがあれば読む
   • 見つかった仕様書の内容を要件と照合し、実装の入力とする
   • 仕様書が見つからない場合はそのまま進める
3. 現在のブランチをベースブランチとして記録する（PR のマージ先）
   • git branch --show-current を実行し、結果をユーザーに「ベースブランチ: <ブランチ名>」と明示的に表示する
   • このブランチ名をフェーズ3のPR作成時まで保持する
4. 作業ブランチ名を決定する（命名規則は references/branch-naming.md を参照）
5. git worktree を作成する（手順は references/worktree-setup.md を参照）
6. 要件を「独立して実装・テストできる単位」に分割
7. 依存関係を整理し実装順を決定
8. TaskCreate でタスクを作成

• コードベースの探索・理解を行い要件を正確に把握する
• 不確定な仕様はユーザーに確認する
• 破壊的変更がある場合は下位互換性についてユーザーに確認する

フェーズ2: 実装サイクル（各スコープで繰り返し）

重要: フェーズ2のすべてのサブエージェント呼び出しで worktree パスを作業ディレクトリとして指定すること。

各スコープ開始時に TaskUpdate で該当タスクを in_progress にする。

2-1: Plan

• Plan エージェントで実装計画を立てる
• 変更箇所、影響範囲、テスト要件を明確にする
• プロンプトに worktree パスを含める

2-2: Develop

• develop エージェントで実装（テスト含む）
• 最小限の変更で要件を満たす
• プロンプトに worktree パスを含める
• 本番動作するコードを書くこと。以下は実装完了とみなさない：
  • モック・スタブ・ダミーだけのテスト（実コードなし）
  • TODO, NotImplementedError, pass, throw new Error("not implemented") で埋めた関数
  • インターフェース・型定義だけで中身がない実装

2-3: Review

• review エージェントでコードレビュー
• 要件適合、コード品質、テスト十分性を評価
• プロンプトに worktree パスを含める
• 未実装チェック: モック/スタブのみ、TODO/NotImplementedError、空の関数本体がないか確認

2-4: 改善サイクル

• レビュー指摘あり → develop で修正 → review で再レビュー → 指摘なしまで繰り返す

2-5: Format & Lint

• プロジェクト設定に従い変更ファイルに format/lint を実行
• worktree ディレクトリ内で format/lint コマンドを実行する
• 設定が見つからない場合はスキップ

2-6: Commit（必須）

• 各スコープ完了時に必ずコミットする。スキップ不可。
• worktree ディレクトリ内で git add / git commit を実行する
• コミットメッセージは CLAUDE.md の規約に従う
• コミット後に TaskUpdate で該当タスクを completed にする

フェーズ3: 完了確認とPR作成

1. 全スコープの実装完了を確認
2. worktree ディレクトリ内で 全体テストを実行
3. worktree ディレクトリ内で git push -u origin <作業ブランチ> を実行
4. gh pr create --base <ベースブランチ> でPRを作成
   • ベースブランチはフェーズ1で記録した開始時のブランチを指定する。main や master にフォールバックしないこと。
   • 不明な場合は git log --oneline --graph HEAD...main 等で分岐元を確認する
   • Issue 指定時: タイトルに Issue 番号を含め、PR作成後に gh pr edit <PR番号> --add-issue <Issue URL> でリンクする（Closes は使わない）
   • PR本文: 変更サマリー + 手動チェックリスト（templates/pr-checklist.md を参照）
5. 実装サマリーと worktree パス をユーザーに報告する

報告例:

## 完了
- PR: <URL>
- Worktree: <パス>（確認後 `git worktree remove <パス>` で削除可能）

ルール

• 各スコープは独立して実装・テスト可能な単位にする
• 各スコープ完了時に必ずコミットする。 コミットせずに次へ進まない
• レビュー指摘はすべての重大度（🔴🟠🟡🟢）で修正する
• TaskCreate/TaskUpdate で進捗を管理する
• フェーズ宣言: 各サブステップ（2-1〜2-6）の開始時に ▶ 2-X 開始: <名称>、完了時に ✓ 2-X 完了 を1行表示する。これによりサイレントスキップを防ぐ
• セルフチェック: 各フェーズ完了前に本 SKILL.md の該当セクションを再読し、未実施手順がないか確認してから次フェーズへ進む
• コンパクト（コンテキスト圧縮）発生時は TaskList で現在の進捗を確認してから作業を再開する
• すべての git / ファイル操作は worktree ディレクトリ内で行う。メインの作業ツリーを変更しない。