task-breakdown

name	task-breakdown
description	未完了事項、TODO、作業メモ、ロードマップ、調査結果、レビュー指摘などを読み取り、実行可能なタスクへ分解する場合に使用してください。 大きすぎる作業や曖昧な作業を、目的、背景、範囲、完了条件、成果物、依存関係、明示された順序が分かる作業単位へ整理します。

作業分解スキル

このスキルは、未完了事項や大きな作業を、着手・レビュー・完了判定しやすいタスク単位へ分解するための手順を提供する。

ここでの「タスク」は、特定ツールの項目に限らない。TODO、バックログ項目、作業依頼、調査タスク、設計タスクなど、実行可能な作業単位を広く指す。

有効化するタイミング

• ユーザーが作業を細分化したい場合
• 未完了事項、TODO、作業メモ、ロードマップ、調査結果、レビュー指摘を整理したい場合
• 大きすぎる作業を、実行可能な単位へ分けたい場合
• 依存関係や明示された順序を整理したい場合
• 作業者や作業エージェントに渡せるタスク案を作りたい場合
• 何を完了とすればよいか曖昧な作業を明確化したい場合

適用しないタイミング

• ユーザーがすぐに実装・修正を求めており、作業分解を求めていない場合
• 単純な一問一答、説明、翻訳、要約だけで足りる場合
• 既に十分小さい単一タスクで、分解によって管理コストだけが増える場合
• コードレビュー、文書レビュー、脆弱性分析など、別の専門スキルで指摘を出すこと自体が主目的の場合

併用するスキル

• 作業前の承認が必要な場合は approval-driven-workflow を併用する。
• 入力となる文書やコードの読解量が多い場合は code-reading または document-review の観点を使う。
• タスク案をドキュメントへ反映する場合は document-write を併用する。
• セキュリティ観点の作業分解では vulnerability-analysis 系のスキルを先に使い、抽出した論点をタスク化する。

基本方針

タスクは、原則として 1 つの成果物または 1 つの明確な完了条件で閉じられる粒度にする。

• 新規実装
• 既存改修
• 調査および検証
• 方針の決定
• 運用・手順化
• ドキュメント更新

...など

方針決定と実作業は分離するし、実作業には依存元のタスクを明記する。
そのため、依存関係がある場合は、前提タスクを明記する。順序は入力元に明示されている場合だけ記載する。

粒度の分け方

• 実装、調査、設計、検証、文書化が大きく異なる責務の場合は分ける。
• 方針決定と実装は分ける。
• 影響範囲が大きい変更は、設計判断、最小実装、失敗系テスト、ドキュメント更新を分ける。
• リファクタリングは、責務単位や境界単位で分ける。
• 1 タスクの完了条件が複数の大きな成果物にまたがる場合は、さらに分割を検討する。
• 小さすぎて単独の成果物がないものは、関連タスクのサブタスクに寄せる。

タスク起票テンプレート

## 説明

タスクの概要

## 背景

なぜ必要か、どの文脈から出てきたか

## 目的

このタスクで達成すること

## 完了条件

何が満たされれば閉じてよいか

## 成果物

実装変更、設計メモ、調査コメント、手順書、テスト、設定変更、後続タスク一覧など

## 依存

前提になるタスク、方針、実装、外部作業

## 参照

元になった文書、コメント、コード、関連タスク。

## 補足

注意点

• 着手、レビュー、完了判断の明確化を目的としてタスクを分解すること
• 特定ツールの分類、期限、担当者、状態は、ユーザーの指示がない限り勝手に設定しない。