version: "1.0.0" name: task-execution description: 依頼の受け取りから完了報告までの汎用タスク遂行プロトコル。あらゆる開発タスクに着手するとき、「どう動くか」の判断基準として常に参照する。

タスク遂行プロトコル

目的

優秀なエンジニアが暗黙にやっている「依頼の解釈→現状把握→計画→実行→検証→報告」の動き方を明文化し、どのモデルが司令塔でも同じ品質でタスクが進む状態を作る。

使うタイミング

• あらゆる開発タスクの着手時
• 「何から手をつけるか」が曖昧なとき
• 依頼を受け取ったが要件が完全に固まっていないとき
• 行き詰まってリカバリが必要なとき

進め方

フェーズ1: 依頼を解釈する

1. 目的(なぜ)を掴む

表面的な指示ではなく、その依頼がなぜ必要なのかを確認する。 「ボタンを赤にして」→「どの画面で・誰が・何の目的で使うボタンか」を理解してから手を動かす。

1. 成果物と完了条件を自分の言葉で定義する

着手前に「〜ができる状態」という完了条件を書き出す。 曖昧語は着手前に具体化する:「いい感じに」→「○○の基準を満たす」、「など」→「具体的に列挙する」。

1. 不明点を仕分ける

• 確認が必要なもの: スコープ・要件の矛盾・不可逆操作の判断
• 自分で決めてよいもの: 可逆で影響が小さい実装の詳細

フェーズ2: 現状を把握する

1. 既存コード・規約・経緯を確認する([[codebase-exploration]])

• CLAUDE.md・README.md・設定ファイルを読む
• 類似の既存実装パターンを検索する
• 過去のコミット・PR・イシューで経緯を確認する

現状把握を飛ばして着手すると、既存パターンと噛み合わないコードになる。

フェーズ3: 計画を立てる

1. タスク開始時メモを書く

後述のテンプレートで依頼の要約・目的・完了条件・不明点の扱い・計画を整理する。 大きいタスクは [[task-breakdown]] でサブタスクに分割する。

1. 「動く状態」を経由する計画にする

最初に全体の骨格(歩くスケルトン)を動かし、そこに肉付けする順序で計画を立てる。 最後まで何も動かない横切り実装は避ける。

フェーズ4: 実行する

1. 小さく進め、動く状態を保つ([[implementation]])

1コミット = 1意図。動く状態を保ったままインクリメンタルに進める。 エラーは握りつぶさない。catch (e) {} は禁止。

1. 行き詰まりのリカバリ([[debugging]])

同じアプローチで3回失敗したら方法を変える。前提を疑う。 設定した時間枠(目安: 2時間)で進展がなければ、状況を整理してユーザーに報告・相談する。

フェーズ5: 検証する

1. 「動くはず」禁止。実際に確認してから完了と言う([[testing]])

• コードを実行・テストする
• lint・型チェックを通す
• 依頼内容の完了条件と突き合わせる
• 失敗したテストを「たぶん関係ない」で流さない

フェーズ6: 報告する

1. 結論先行で報告する

「できた/できない/部分的にできた」を最初に書く。 やったこと・検証したこと・自分で決めたこと・残課題を簡潔に添える。 悪い報告(失敗・ブロック)ほど早く伝える。

1. 中断に備えて記録を残す([[session-handoff]])

長時間タスクや途中で中断する可能性があるときは、途中状態・未完了の手順・次のアクションを記録する。

聞くべきこと・自分で決めてよいことの判断

聞き方の原則: 選択肢と推奨案をセットで提示する。 悪い例:「どうしますか?」 良い例:「AとBの方法があります。○○の理由でAを推奨しますが、Bにする理由があれば教えてください」

成果物テンプレート

タスク開始時メモ

## タスク開始メモ: [タスク名]
 
### 依頼の要約
[依頼を自分の言葉で1〜3文に要約]
 
### 目的(なぜ)
[この依頼がなぜ必要か。背景・ユーザーへの価値]
 
### 完了条件
-[ ] [検証可能な条件1]
-[ ] [検証可能な条件2]
 
### 不明点と扱い
| 不明点 | 扱い(確認する / 自分で決める) | 決める場合の方針 |
|---|---|---|
| [不明点] | [扱い] | [方針] |
 
### 計画
1.[ステップ1]
2.[ステップ2]
3....
 
### 委譲計画(並列化できるサブタスクがあれば)
-[サブタスクA] → Sonnet相当
-[サブタスクB] → Haiku相当

完了報告の型

## 完了報告: [タスク名]
 
**結果**: [完了 / 部分的に完了(残課題あり) / 未完了(理由)]
 
### やったこと
-[変更内容1]
-[変更内容2]
 
### 検証したこと
-[テスト実行結果: XX件パス]
-[lint: エラーなし]
-[完了条件との突き合わせ: ○ / ×(理由)]
 
### 自分で決めたこと
-[判断1]: [理由]
 
### 残課題・懸念
-[残っている作業や注意点]

チェックリスト

• [ ] 完了条件を着手前に書き出した
• [ ] 曖昧語を具体化した
• [ ] 既存コード・規約を確認した
• [ ] 現状把握を飛ばさなかった
• [ ] 実際に実行・テストした
• [ ] lint・型チェックを通した
• [ ] 失敗テストを握りつぶしていない
• [ ] 自分で決めた事項を報告に含めた
• [ ] 不可逆操作の前に確認した
• [ ] 中断可能な状態で記録を残した

アンチパターン

• 思い込み着手: 現状把握を飛ばして実装を始め、既存パターンと噛み合わない大量のコードを書く
• 検証なしの完了宣言: 実行・テストをせずに「できました」と報告する
• 10秒で聞けることを1時間調査: 自分では判断できないことをユーザーに確認せず抱え込む
• 逆パターン: 自分で確認できることをユーザーに聞く: コードを読めば分かることを質問して時間を取らせる
• エラーの握りつぶし: テスト失敗・lintエラーを「たぶん関係ない」で無視して進める
• 進捗ゼロの無言: 行き詰まっても報告せず、長時間何も届けない
• スコープクリープ: 依頼より大きいことを勝手にやる。「ついでに」の改修は別タスクとして提案する
• 前提の固執: 同じアプローチで何度も失敗しているのに方法を変えない

モデル委譲ガイド

共通原則は [[orchestration]] を参照。

関連スキル

• [[orchestration]] — モデル委譲の共通原則
• [[codebase-exploration]] — 現状把握・既存コードの調査
• [[task-breakdown]] — 大きいタスクのサブタスク分割
• [[implementation]] — コーディングフェーズの詳細手順
• [[testing]] — 検証・テスト戦略
• [[debugging]] — 行き詰まり時のリカバリ
• [[session-handoff]] — 中断時の引き継ぎ記録
• [[skill-navigator]] — 使うスキルの選択