task-management

タスク管理

概要

タスク管理では、承認済みの計画を小さく追跡可能なタスクに分割し、進捗報告とチェックポイントレビューを通じて実行を調整します。各タスクは、2～5分で完了する単一のアクションです。このスキルでは、実行中の品質を維持するため、体系的な進捗追跡、定期的なチェックポイント、コードレビューとの連携を行います。

開始時に宣言：「タスク管理スキルを使用して、この計画を追跡可能なタスクに分割します。」

トリガー条件

• 承認済みの計画書を実行可能なタスクに変換する必要がある
• 複数のステップからなる実装を体系的に進捗追跡する必要がある
• 定期的なチェックポイントレビューが必要である
• タスクの分割が必要な計画で /execute コマンドが使用された
• 承認済みの計画を伴うプランニングスキルからの移行

---

フェーズ 1：計画の解析

目標： 承認済みの計画から、順序と依存関係が正しいすべてのタスクを抽出します。

1. 承認済みの計画書を最初から最後まで読む
2. 実装ステップをすべて個別のタスクとして抽出する
3. タスク間の依存関係（先に完了すべきタスク）を特定する
4. 依存関係に基づいてタスクを並べ替える — 独立したタスクを先にする
5. 実行を開始する前に、タスクリストをユーザーに確認する

タスクの粒度ルール

粒度	例	判定
単一のアクション、2～5 分	「UserService.create の失敗するテストを書く」	適切
単一のアクション、2～5 分	「テストを実行して失敗することを確認する」	適切
単一のアクション、2～5 分	「テストに合格する最小限のコードを実装する」	適切
複数のアクション、30 分以上	「認証システムを実装する」	大きすぎる — 分割する
簡単すぎる、1 分未満	「空行を追加する」	小さすぎる — 隣接するタスクと統合する

タスク仕様テンプレート

Task N: [Clear, specific description]
Files: [Exact paths to create/modify/test]
Depends on: [Task numbers that must complete first, or "none"]
Verification: [Exact command to confirm completion]

停止 — 以下を満たすまでフェーズ 2 に進まないでください：

• 計画のすべてのステップが、2～5 分のタスクに変換されている
• 依存関係が整理されている（循環依存がない）
• すべてのタスクに検証コマンドがある
• タスクリストがユーザーに確認されている

---

フェーズ 2：タスクの実行

目標： タスクを一度に 1 つずつ実行し、それぞれの後に検証します。

タスクごとのワークフロー

1. 告知 — 開始するタスクを報告する：[N/Total] Starting: <description>
2. ステータスを設定 — タスクを in_progress にする
3. 実行 — タスクを実施する（コードを書く場合は TDD に従う）
4. 検証 — 検証コマンドを実行する
5. 出力を読む — 検証結果が成功条件を満たしていることを確認する
6. 報告 — 完了を示す：[N/Total] Completed: <description>
7. ステータスを設定 — タスクを completed にする

実行ルール

ルール	理由
一度に 1 つのタスクを実行する	コンテキスト切り替えによるエラーを防ぐ
完了にする前に検証する	誤った完了判定を防ぐ
検証出力を最後まで読む	出力の一部だけを見て成功と判断しない
コードタスクでは TDD に従う	RED-GREEN-REFACTOR サイクル
先のタスクに飛ばない	依存関係が満たされていない可能性がある

タスクのステータスフロー

pending → in_progress → completed
                     → blocked (needs user input)
                     → failed (invoke resilient-execution)

ステータス判定表

結果	新しいステータス	アクション
検証に合格	completed	次のタスクに進む
検証に失敗し、修正可能	in_progress	修正して再検証する
検証に失敗し、原因が不明	failed	resilient-execution スキルを呼び出す
ユーザーの判断が必要	blocked	ブロッカーを報告し、タスクを一時停止する
ブロック中のタスクに依存している	pending	ブロックされていない次のタスクに進む

現在のタスクの検証に合格するまで、次のタスクに進まないでください。

---

フェーズ 3：チェックポイントレビュー

目標： 3 タスクごとに一時停止し、進捗と品質を評価します。

チェックポイントのトリガー表

条件	アクション
前回のチェックポイントから 3 タスクが完了した	必須のチェックポイント
論理的な作業単位（例：1 つのコンポーネント）が完了した	チェックポイントを推奨
テスト失敗が発生した	直ちにチェックポイント
ユーザーから状況確認の依頼があった	臨時のチェックポイント

チェックポイントの手順

1. 進捗の概要を表示する
2. テストスイート全体を実行する（新しいテストだけではなく）
3. 必要に応じて、リンター、型チェック、ビルドを実行する
4. 重要なコードを書いた場合は、code-review スキルをディスパッチする
5. この方向性で引き続き進めてよいか、ユーザーに確認する

進捗レポートの形式

各タスクの後：

[3/15] Task completed: Write failing test for UserService.create
       Files: tests/services/user.test.ts
       Verification: npm test -- --grep "UserService.create" — PASS

各チェックポイントの後：

── Checkpoint [6/15] ──
Completed: 6 | Remaining: 9 | Blocked: 0
Tests: 12 passing, 0 failing
Lint: clean | Build: passing
Next batch: Tasks 7-9 (API endpoint implementation)
Continue? [yes / adjust plan / stop here]

停止 — 次のバッチに進む前に、以下を完了してください：

• テストスイート全体が成功している
• チェックポイントレポートをユーザーに提示している
• ユーザーが続行を確認している

---

フェーズ 4：バッチレビュー

目標： 論理的なタスクのまとまりを完了した後、品質レビューを行います。

1. バッチをレビューする code-reviewer エージェントをディスパッチする
2. 重大または重要な問題があれば、先に進む前に修正する
3. 説明的な Conventional Commit メッセージを付けてバッチをコミットする
4. 完了状況を反映するよう、計画ドキュメントを更新する

レビューでの問題への対応

重大度	対応	続行するか？
重大	直ちに修正する必要があります	いいえ — 先に修正する
重要	次のバッチに進む前に修正するべきです	条件付き — ユーザーが判断する
提案	今後のために記録する	はい — 続行する

停止 — 次のバッチを開始する前に、以下を完了してください：

• 重大度が「重大」のレビュー項目を解決している
• バッチをコミットしている
• 計画ドキュメントを更新している

---

フェーズ 5：完了

目標： すべてのタスクが完了していることを確認し、最終状況を報告します。

1. すべてのタスクのステータスが completed であることを確認する
2. 最後にテストスイート全体を実行する
3. すべての検証コマンドを実行する
4. 最終概要をユーザーに提示する
5. verification-before-completion スキルを呼び出す

最終概要の形式

── FINAL SUMMARY ──
Total tasks: 15 | Completed: 15 | Failed: 0
Tests: 42 passing, 0 failing
Build: passing | Lint: clean
Commits: 5 (conventional format)

All tasks from plan docs/plans/2026-03-15-feature.md are complete.
Verification-before-completion: PASS

---

アンチパターン／よくある間違い

アンチパターン	失敗する理由	正しい対応
検証せずに完了とする	進捗を誤認し、バグが蓄積する	検証コマンドを実行し、出力を読む
5 分を超えるタスク	追跡が難しく、スコープクリープが起きやすい	タスクを 2〜5 分単位に分割する
チェックポイントを省略する	品質が低下し、方向性がずれていく	3 タスクごとにチェックポイントを設ける
新しいテストだけを実行する	リグレッションを検出できない	チェックポイントでテストスイート全体を実行する
依存関係のあるタスクを並列化する	競合状態やマージコンフリクトが発生する	本当に独立している場合を除き、一度に 1 タスクだけ進める
ブロックされたタスクを黙って飛ばして先に進む	ユーザーが作業の省略に気づかない	すべてのブロッカーを明示的に報告する
バッチの区切りでコミットしない	変更セットが大きくなり、レビューしにくくなる	論理的なバッチごとにコミットする
「動いているから、検証は後でやる」	後回しにしたまま実行されない	今すぐ検証する

---

不合理な正当化を防ぐガード

検証なしに完了とマークしてはいけません。検証コマンドを実行してください。出力を読んでください。期待どおりであることを確認してください。その後に限り、完了とマークしてください。

次のように考えていることに気づいたら：

• 「コードは正しそうだから、実行しなくてもよい……」— 実行してください。必ず。
• 「検証をまとめて実行しよう……」— いいえ。各タスクを個別に検証してください。
• 「このタスクは簡単だから、問題なく動くはず……」— 検証して証明してください。

---

連携ポイント

スキル	関係	タイミング
planning	上流 — 承認済みの計画を提供する	タスクリストの参照元
executing-plans	補完 — 計画の実行フローを扱う	組み合わせて使用可能
test-driven-development	タスクごと — コードタスクの TDD サイクル	すべてのコードタスク
verification-before-completion	タスクごと — 検証ゲート	タスクを完了とマークする前
resilient-execution	失敗時 — 別の方法で再試行する	タスクの検証に失敗した場合
code-review	チェックポイント — バッチの品質レビュー	3 タスクごと、またはバッチの区切り
subagent-driven-development	代替 — 並列実行パス（Agent ツール経由）	独立したタスクのバッチの場合
Agent ツール	ディスパッチ機構 — すべてのサブエージェント作業に使用	独立したタスクを並列化する場合
circuit-breaker	セーフティネット — 停滞を検出する	タスクが繰り返し失敗する場合

---

具体例

例：計画からのタスク抽出

計画のステップ：「検証機能付きのユーザー登録エンドポイントを追加する」

抽出されたタスク：

Task 1: Write failing test for POST /api/users input validation
  Files: tests/api/users.test.ts
  Depends on: none
  Verification: npm test -- --grep "POST /api/users validation" → FAIL (expected)

Task 2: Implement input validation schema
  Files: src/schemas/user.ts
  Depends on: Task 1
  Verification: npm test -- --grep "POST /api/users validation" → PASS

Task 3: Write failing test for POST /api/users success case
  Files: tests/api/users.test.ts
  Depends on: Task 2
  Verification: npm test -- --grep "POST /api/users creates user" → FAIL (expected)

Task 4: Implement registration endpoint handler
  Files: src/routes/users.ts
  Depends on: Task 3
  Verification: npm test -- --grep "POST /api/users" → ALL PASS

Task 5: Commit registration endpoint
  Files: none (git operation)
  Depends on: Task 4
  Verification: git log --oneline -1 → shows conventional commit

例：ブロックされたタスクの報告

BLOCKED: Task 7 — Write integration test for payment webhook
Reason: Stripe test API key not configured in .env.test
Impact: Tasks 7-9 (payment flow) cannot proceed
Non-blocked tasks: Tasks 10-12 (profile page) can continue

Options:
A. User provides Stripe test key → unblocks Tasks 7-9
B. Skip payment tasks, continue with profile → revisit later
C. Mock Stripe entirely → reduces test fidelity

Awaiting direction.

---

重要な原則

• 一度に1つのタスク — タスクが本当に独立している場合を除き、並行して進めないでください
• 各タスクの後に検証する — 完了としてマークする前に、検証コマンドを実行してください
• 定期的にチェックポイントを設ける — 3つのタスクごとに一時停止して状況を確認してください
• すべてを追跡する — ステータスのないタスクを作らないでください
• 小さなコミット — 論理的なまとまりごとにコミットしてください

---

スキルタイプ

RIGID — このプロセスに厳密に従ってください。すべてのタスクを検証します。3つのタスクごとにチェックポイントを設けます。例外はありません。