structured-workflowlisted

# Structured Workflow リサーチ → 計画 → 実装の3段階で複雑なタスクを進めるワークフロー。各段階でユーザーの承認を得てから次に進む。計画段階の**アノテーションサイクル**（ユーザーのインラインコメントを反復的に反映）が中核。 ## 設計哲学 このワークフローは以下の原則に基づいている: - **「実装は退屈であるべき」**: 創造的な意思決定はすべて計画段階で完了させる。実装は機械的な作業にする。これにより、Claude が初期段階で誤った仮説を立て、長時間かけて構築した結果をほどくという失敗パターンを排除する - **ファイルベースの計画管理**: Claude Code のビルトインプラン機能ではなく、markdown ファイル（plan.md）を使う。理由は 3 つ: ①ユーザーがエディタで自由に編集できる、②完全な制御が可能、③プロジェクト内に永続化されコンテキスト圧縮後も参照できる - **ユーザーが常に Driver's Seat にいる**: Claude に完全な自律性を与えない。ユーザーが意思決定権を持ち、Claude はそれに従う ## ワークフロー全体像 ``` Stage 0: スコーピング → [ユーザー承認] Stage 1: リサーチ → research.md 作成 → [ユーザーレビュー・承認] Stage 2: プランニング → plan.md 作成 → [アノテーションサイクル] → [ユーザー承認] Stage 3: 実装 → plan.md の TODO 消化 → [ユーザーレビュー] ``` **ガードレール:** 各ステージのユーザー承認なしに次のステージへ進まない。特に「計画承認前の実装着手」は厳禁。 ## 初回オファー ユーザーに構造化ワークフローを提案する。 1. 4 つのステージを簡潔に説明する 2. タスクの複雑度に対してこのワークフローが適切か判断を仰ぐ 3. ユーザーが受け入れたら Stage 0 へ進む。辞退したらフリーフォームで対応する ## Stage 0: スコーピング **目的:** タスクの範囲・制約・成功基準を明確にする。 ### プロセス 1. ユーザーのタスク説明を聞く 2. 以下を明確化する質問を 3-5 問する: - 最終的なゴール・成果物は何か - 対象範囲（何を含み、何を含まないか） - 制約条件（技術的制約、時間、既存システムとの整合性） - 成功基準（何をもって完了とするか） - 優先順位（複数の要件がある場合） 3. ユーザーの回答をもとにスコープを 1 段落で要約する ### ゲート スコープ要約をユーザーに提示し、合意を得る。合意が得られたら Stage 1 へ進む。 ## Stage 1: リサーチ **目的:** タスクに関連するドメイン・コードベース・コンテキストを深く調査し、research.md にまとめる。 **なぜリサーチが重要か:** Garbage in, garbage out。リサーチが間違えば計画も成果物も間違う。最大の失敗モードは個別のミスではなく、**既存の仕組み・慣例・文脈との不整合**である。例: - コードタスク: 既存のキャッシング層を無視する関数、ORM の慣例を無視するマイグレーション、既存ユーティリティと重複するロジック - ドキュメントタスク: 既存の用語集と矛盾する表現、他ドキュメントと重複する内