task-splitting

タスク分割

ソース文書を明確なタスク境界に分割します。分解と作成は分けてください。まず草案を作成して検証し、ユーザーの明示的な承認を得てから agent-team タスクを作成します。

ワークフロー

1. ソース文書を受け取ります。
2. 目標、制約、成果物、対象外の事項、曖昧な点を抽出します。
3. brainstorming が必要かどうかを判断します。
4. 機能の境界ごとにタスクを起草します。
5. すべてのタスク境界を検証します。
6. タスクごとにタスクファイルを1つ作成します。
7. 確認を求めます。
8. 承認済みのファイルから agent-team タスクパッケージを作成します。

1. ソースを受け取る

• 文書の本文またはローカルの文書パスを受け付けます。
• 分解に必要なファイルのみを読み込みます。
• 文書に目標、成果物、またはタスクファイルの出力先が記載されていない場合は、草案の作成前に確認します。
• ユーザーがタスクファイルの保存先を指定していない場合は、1回だけ確認します。指定にこだわらない場合は、ソース文書の隣に <document-stem>-tasks/ という名前のディレクトリを作成し、そこに保存します。
• タスクのスコープを定める唯一の根拠として、ソース文書とユーザーの補足説明を扱います。

2. brainstorming を使うかどうか判断する

次のいずれかに該当する場合は、タスクの草案を作成する前に brainstorming を呼び出します。

• 文書の目標が曖昧である
• スコープに矛盾がある
• 複数の分解方法が同程度に妥当である
• 複数の機能が複雑に絡み合っている
• ユーザーがタスクの草案作成前に話し合うことを希望している

明確で範囲の定まった文書に対して、無理に brainstorming を使う必要はありません。

3. 機能の境界ごとに分解する

次のルールを厳守してください。

• ユーザーから見える機能1つ、または明確なサブ機能1つを、タスク1つとすることを優先します。
• 各タスクの主要な責任は、必ず1つだけにします。
• タスクの境界を明確にします。
• 段落ごとではなく、機能ごとにタスクを作成することを優先します。
• スコープが混在する場合は、文書のセクションごとにまとめないでください。
• 文書内で一緒に説明されているという理由だけで、複数の機能を統合しないでください。

次のいずれかに該当する場合は、タスクを分割します。

• 相互に独立した複数の機能が含まれている
• 受け入れ対象が複数含まれている
• 構築と検証の責任が混在している
• 依存関係の連鎖により、独立して実行できるかどうかが不明確である

4. すべてのタスク境界を検証する

有効なタスクには、次のすべてが含まれている必要があります。

• 機能またはサブ機能が必ず1つである
• 主要な責任が必ず1つである
• 完了条件が明確である
• スコープ内のセクションが明記されている
• スコープ外のセクションが明記されている
• 受け入れ基準が明記されている
• 依存関係が管理可能である

いずれかの確認に不合格となった場合は、ファイルを書き込む前にタスクを分割するか、書き直してください。

5. タスクごとにタスクファイルを1つ作成する

• 1つのタスクを、1つのタスク定義ファイルに対応させます。
• タスクファイルを、タスク境界を定義する正式な情報源として扱います。
• 01-auth-login.md、02-auth-session-check.md のように、安定してレビューしやすい命名にします。
• references/task-file-template.md のテンプレートを使用します。
• タスクファイルを個別に作成する代わりに、複数タスクをまとめた概要ファイルを作成しないでください。

6. 作成前に確認を求める

• 起草したタスク一式を提示し、レビューを求めます。
• 曖昧な点や未解決の質問を明示します。
• agent-team タスクを作成する前に、明示的な承認を求めます。
• ユーザーが変更を求めた場合は、まずタスクファイルを更新します。作成段階でスコープを再定義しないでください。

7. 承認済みファイルから agent-team タスクを作成する

プロジェクトで agent-team CLI が利用できる場合は、承認済みのタスクファイルごとにタスクパッケージを1つ作成します。

確認済みのコマンド形式：

agent-team task create --role <role> "<title>" --design "<task-file>"

ルール：

• 承認前にタスクを作成しないでください。
• タスクファイルに記載されたタイトル、スコープ、依存関係、受け入れ条件をそのまま保持します。
• 作成中にスコープを再解釈したり、拡張したりしないでください。
• --role は必須です。文書またはタスクファイルで指定されたロールを使用してください。指定がない場合は推測せず、ユーザーに確認します。
• 成功と失敗の結果を正確に報告します。
• 作成に一部失敗した場合は停止し、作成済みのタスクと失敗した内容を明示して返します。

出力の契約

下書きフェーズの出力

以下を返します。

• 分解内容の簡単な要約
• 下書きしたタスクタイトルの一覧
• 各タスクファイルのファイルパス
• 未解決の境界に関する質問
• 明示的な承認依頼

作成フェーズの出力

以下を返します。

• 作成した各タスクタイトル
• 元のタスクファイル
• 作成されたタスク ID（取得できる場合）
• 失敗した場合は、失敗した正確なファイル名

ガードレール

• コードの変更を実装しないでください。
• 作成フェーズでスコープを書き換えないでください。
• 分析、実装、テストを1つのタスクにまとめないでください。
• 境界がすでに明確な場合は、brainstormingを無理に適用しないでください。