| name | task-breakdown |
| description | 未完了事項、TODO、作業メモ、ロードマップ、調査結果、レビュー指摘などを読み取り、実行可能なタスクへ分解する場合に使用してください。
大きすぎる作業や曖昧な作業を、目的、背景、範囲、完了条件、成果物、依存関係、明示された順序が分かる作業単位へ整理します。
|
作業分解スキル
このスキルは、未完了事項や大きな作業を、着手・レビュー・完了判定しやすいタスク単位へ分解するための手順を提供する。
ここでの「タスク」は、特定ツールの項目に限らない。TODO、バックログ項目、作業依頼、調査タスク、設計タスクなど、実行可能な作業単位を広く指す。
有効化するタイミング
- ユーザーが作業を細分化したい場合
- 未完了事項、TODO、作業メモ、ロードマップ、調査結果、レビュー指摘を整理したい場合
- 大きすぎる作業を、実行可能な単位へ分けたい場合
- 依存関係や明示された順序を整理したい場合
- 作業者や作業エージェントに渡せるタスク案を作りたい場合
- 何を完了とすればよいか曖昧な作業を明確化したい場合
適用しないタイミング
- ユーザーがすぐに実装・修正を求めており、作業分解を求めていない場合
- 単純な一問一答、説明、翻訳、要約だけで足りる場合
- 既に十分小さい単一タスクで、分解によって管理コストだけが増える場合
- コードレビュー、文書レビュー、脆弱性分析など、別の専門スキルで指摘を出すこと自体が主目的の場合
併用するスキル
- 作業前の承認が必要な場合は
approval-driven-workflow を併用する。
- 入力となる文書やコードの読解量が多い場合は
code-reading または document-review の観点を使う。
- タスク案をドキュメントへ反映する場合は
document-write を併用する。
- セキュリティ観点の作業分解では
vulnerability-analysis 系のスキルを先に使い、抽出した論点をタスク化する。
基本方針
タスクは、原則として 1 つの成果物または 1 つの明確な完了条件で閉じられる粒度にする。
- 新規実装
- 既存改修
- 調査および検証
- 方針の決定
- 運用・手順化
- ドキュメント更新
...など
方針決定と実作業は分離するし、実作業には依存元のタスクを明記する。
そのため、依存関係がある場合は、前提タスクを明記する。順序は入力元に明示されている場合だけ記載する。
粒度の分け方
- 実装、調査、設計、検証、文書化が大きく異なる責務の場合は分ける。
- 方針決定と実装は分ける。
- 影響範囲が大きい変更は、設計判断、最小実装、失敗系テスト、ドキュメント更新を分ける。
- リファクタリングは、責務単位や境界単位で分ける。
- 1 タスクの完了条件が複数の大きな成果物にまたがる場合は、さらに分割を検討する。
- 小さすぎて単独の成果物がないものは、関連タスクのサブタスクに寄せる。
タスク起票テンプレート
## 説明
タスクの概要
## 背景
なぜ必要か、どの文脈から出てきたか
## 目的
このタスクで達成すること
## 完了条件
何が満たされれば閉じてよいか
## 成果物
実装変更、設計メモ、調査コメント、手順書、テスト、設定変更、後続タスク一覧など
## 依存
前提になるタスク、方針、実装、外部作業
## 参照
元になった文書、コメント、コード、関連タスク。
## 補足
注意点
- 着手、レビュー、完了判断の明確化を目的としてタスクを分解すること
- 特定ツールの分類、期限、担当者、状態は、ユーザーの指示がない限り勝手に設定しない。