Task Performer
TODOタスクを読み込み、計画・実装・テスト・Lintまでを一貫して実行する。
スコープ
含むもの
- タスクドキュメント（task-starter生成 or 直接指示）に基づくコード実装
- テスト・Lintの実行と修正
- 変更ファイルのステージングとコミットログファイルの出力
- タスクドキュメントへの完了状態の反映
含まないもの
- タスクドキュメントの新規作成・分割（→ task-starter）
git commit/git pushの実行（ユーザーに委ねる）- 既存コードのリファクタリング（タスク要件に含まれない限り）
- インフラ構築・デプロイ作業
ユースケース
ユースケース: TODOタスクの実装
トリガー: 「このタスクを実装して」「/task-performer docs/tasks/todos/001-setup/README.md」
「TODOを実行して」「このタスクドキュメントに基づいて実装して」
手順:
1. タスク情報を受け取る（ファイルパスまたは直接指示）
2. 影響範囲を分析し、実装計画を立案
3. ユーザー承認後、コード実装・テスト・Lintを実行
4. 作業結果を報告し、承認後にステージング・コミットログ出力
成功基準:
- タスクで定義された要件がすべて実装されていること
- テストが全件パスしていること
- Lintエラーがゼロであること
- 変更ファイルがgit addされ、コミットログファイルが出力されていること
Degrees of Freedom
- タスク分析・計画立案: High freedom — タスクの性質に応じて影響範囲の分析方法、実装ステップの粒度、リスク評価の深さを判断する
- ユーザー確認タイミング: Low freedom — Phase 3（計画レビュー）とPhase 7（作業結果レビュー）でのAskUserQuestion実行は必須。省略しない
- コミットログ形式: Low freedom — Conventional Commits形式、1行72文字以内のルールに従う
- テスト・Lint実行: Low freedom — 失敗時は修正→再実行を繰り返し、パスするまで完了としない
ワークフロー
Phase 1: タスク情報の受け取り
タスク情報を以下のいずれかで受け取る:
- ファイルパス: todos/001-setup/README.md のようなパスを読み込む
- 直接指示: プロンプトで指定された内容を使用
タスク情報が不明確な場合はAskUserQuestionで確認する。
task-starterプロジェクトの自動認識
ファイルパスが todos/ を含む場合、task-starterで生成されたプロジェクト構造と判断し、プロジェクトルート（YYYYMMDD-{name}/）を特定して関連資料を自動読み込みする。
YYYYMMDD-{name}/ ← プロジェクトルート
├── README.md # プロジェクト概要・目的
├── specs/ # 要件・技術仕様書
├── references/ # 現状分析資料（既存コード改修時）
├── todos/ # タスクドキュメント
│ └── 001-{task}/
│ └── README.md ← 指定されたタスクファイル
└── logs/ # 作業ログ出力先
└── 001-{task}/
読み込み手順:
- 指定されたタスクファイル（
todos/NNN-{task}/README.md）を読み込む - プロジェクトルートの
README.mdを読み込む（プロジェクト全体の目的を把握） specs/配下の全ファイルを Glob で探索し読み込む（要件・技術仕様の把握）references/配下のファイルを Glob で探索し読み込む（現状分析の把握）logs/配下の同一タスク番号のディレクトリを確認し、既存ログがあれば読み込む（過去の作業経緯の把握）
※ ステップ2-5は並列で実行する。
Phase 2: 作業計画の立案
- リファレンス確認: task-starterプロジェクトの場合はPhase 1で読み込み済みのため省略。それ以外の場合は計画立案に参照するリファレンスの有無をAskUserQuestionで確認
- タスク分析:
- 影響範囲の特定（DB / Backend / Frontend 等）
- 実装ステップの洗い出し
- 必要なテストの特定
- リスクと注意点の識別
Phase 3: 計画レビュー依頼
以下の形式で計画をユーザーに提示し、フィードバックを受ける:
## 実装計画: {タスク名}
### 概要
{タスクの目的と実装方針を1-3文で}
### 実装ステップ
1. {ステップ1}: {内容}
2. {ステップ2}: {内容}
...
### 影響範囲
- {影響を受けるモジュール/ファイル/機能}
### 注意点・リスク
- {リスク1}: {対策}
フィードバックがあれば修正して再提示。承認されたら次へ進む。
Phase 4: 実装
承認された計画に基づき以下の順序で進める:
4-1. DBマイグレーション（DB変更がある場合）
DB変更が発生する場合:
- マイグレーション実行手順をAskUserQuestionで確認（不明な場合）
- 手順に従い実行
- エラー発生時はユーザーに報告して対処方法を確認
4-2. メインコードとテストコードの実装
以下の方針でコードを実装する:
- 既存コードのスタイル（命名規則、インデント、ディレクトリ構成）に合わせる
- 変更は計画で承認された範囲に限定し、関連箇所の「ついで修正」は避ける
- テストコードはメインコードと同時に実装する（後回しにしない）
Phase 5: テスト実行
- テスト実行手順をAskUserQuestionで確認（不明な場合）
- テストを実行
- 失敗した場合: エラー確認 → 修正 → 再実行を繰り返す
Phase 6: Lint実行
- Lint実行手順をAskUserQuestionで確認（不明な場合）
- Lintを実行
- 失敗した場合: エラー確認 → 修正 → 再実行を繰り返す
Phase 7: 作業結果レビュー依頼
以下の形式で報告し、AskUserQuestionで承認/追加修正を確認する:
## 作業結果: {タスク名}
### 実装内容
{何を実装したかの概要を1-3文で}
### 変更ファイル
- `{ファイルパス}`: {変更内容の要約}
- ...
### テスト結果
- 実行コマンド: `{テストコマンド}`
- 結果: {PASS/FAIL} ({N}件中{N}件パス)
### Lint結果
- 実行コマンド: `{lintコマンド}`
- 結果: {エラー0件 / 警告N件}
### 注意点・今後の課題
- {あれば記載、なければ「なし」}
Phase 8: 承認後の処理
承認されたら以下を実施:
- git管理されている変更ファイルのステージング
git add {変更したファイル} - コミットログファイルの出力
- "commit-{
date +'%Y%m%d%H%M%S'コマンドの実行結果}-{title}.txt" というファイル名でファイルに書き出す（git commit -Fで使用） - 出力先: task-starterプロジェクトの場合は
logs/NNN-{task}/配下。それ以外はAskUserQuestionで確認 - 形式:
{Conventional Commits形式のメッセージ} {作業内容の詳細をmarkdown形式で記載} {1行72文字以内}
- "commit-{
- タスクファイル更新（ファイルパスで提供された場合）
- タスクの作業ログや完了状態を、指定されたTODOタスクファイルにも反映
ガイドライン
不明点の確認
以下の場合はAskUserQuestionで必ず確認:
- タスク要件が不明確
- 複数の実装アプローチがある
- 既存コードへの影響範囲が不明
- DBスキーマの変更が必要
- 破壊的変更の可能性がある
情報収集
公式仕様・ベストプラクティスが必要な場合:
- WebFetch/MCPツールで最新情報を収集
- 公式ドキュメントを優先
- 収集情報のソースを明記
エラーハンドリング
共通方針:
- エラーメッセージを正確に確認
- 原因を特定
- ユーザーに報告
- 対処方法を提案または確認
- 修正実施 → 再検証
推測での修正は避ける。
個別パターン:
| エラー | 対応 |
|--------|------|
| タスクファイルが存在しない | エラーを報告し、正しいパスをAskUserQuestionで確認。Globで todos/**/README.md を検索して候補を提示 |
| task-starterプロジェクト構造が不完全 | specs/やreferences/が空でも続行。読み込めたファイルのみで計画を立案し、不足情報はAskUserQuestionで補完 |
| テスト環境が未設定 | AskUserQuestionで確認後、テスト環境がない場合はPhase 5をスキップ。スキップした旨をPhase 7の報告に記載 |
| Lint環境が未設定 | AskUserQuestionで確認後、Lint環境がない場合はPhase 6をスキップ。スキップした旨をPhase 7の報告に記載 |
| テスト/Lintが繰り返し失敗 | 3回修正しても解決しない場合はユーザーに報告し、続行/中断を確認 |
前提条件
- 対象プロジェクトがgit管理下にあること
- テスト実行環境がセットアップ済みであること（未設定の場合はPhase 5をスキップ）
- Lint実行環境がセットアップ済みであること（未設定の場合はPhase 6をスキップ）
禁止事項
- APIキー、パスワード、シークレットのハードコード — セキュリティインシデントの原因となり、git履歴に残ると除去が困難なため
- テストが失敗したコードの放置 — 失敗状態のまま次フェーズに進むと、問題が積み重なり原因特定が困難になるため
- Lintエラーの無視 — コード品質の劣化を防ぎ、既存コードベースとの一貫性を保つため
git commitとgit pushの実行 — レビュー前の意図しないコミットを防ぎ、コミットメッセージやタイミングの最終判断をユーザーに委ねるため