task

task - 計画段階

不変条件

• タスク文書のみを作成または更新します。
• コードは実装しません。
• 計画段階から自動化を開始しません。
• TASKS.md の更新後に作業を停止し、タスクのレビュー準備ができたことをユーザーに伝えます。
• Planned に行を追加した後、引き継ぎ前に TASKS.md を再度読み、その行が存在することを確認します。
• すでに担当者が決まっている、または In Progress のタスク（ワーカーブランチ、オープン PR、またはトラッカー上でその状態にあるタスク）のスコープは絶対に変更しません。新たに判明したことは、それを参照する新しいタスクに記載し、元のタスクを担当するエージェントに連絡するようユーザーに伝えます。担当者がすでに読んだタスク文書を編集しても、そのエージェントには伝わりません。

ランタイムアダプターでは、この段階はスラッシュコマンド、メニューアクション、または自然言語によるスキル呼び出しとして公開される場合があります。移植可能な段階名は task です。

ワークフロー

1. AGENTS.md を読みます。
2. LEARNINGS.md が存在する場合は読みます。
3. 不足している情報によってスコープ、リスク、または受け入れ基準が変わる場合に限り、依頼内容を明確にします。
4. タスクに直接関係するファイルを対象に、コードベースを調査します。
5. 調整確認。 このタスクで変更するファイルを列挙し、他の Planned および In Progress のタスク文書（プロジェクトで使用している場合は、オープン中のワーカーブランチや PR も）を読みます。重複する箇所はすべて Coordination に記録し、共有ファイルと他のタスクを明記します。2 つのタスクが同じファイルを編集する場合は、「{ID} の後にマージ」のような順序ルールを記載します。
6. 未決事項。 ユーザーだけが決められる事項はすべて Open Decisions に記載し、BLOCKING（実装を開始してはいけません）または NON-BLOCKING（既定の方針を明記します）と示します。決定事項を文章の中に埋もれさせないでください。
7. 運用担当者の手順。 変更をマージしただけでは適用されない場合（マイグレーション、別途デプロイするコンポーネントのデプロイ、設定、データのバックフィル）は、その手順を Operator Steps に列挙します。デプロイについては、変更された共有モジュールをインポートするだけのものも含め、影響を受けるすべてのデプロイ可能なコンポーネントを挙げ、特定方法も説明します。
8. 推奨する実行ティアを選択します。
9. テンプレート（「テンプレート」を参照）を使って docs/task/{ID}-{task-name}.md を作成または更新します。
10. TASKS.md の Planned の下にタスクを追加または更新します。
11. ユーザーのレビューと承認を待ちます。

テンプレート

プロジェクト独自の docs/templates/task-document.md および docs/templates/tasks-tracking.md がある場合は、それらを使用します。ない場合は、このスキルに同梱されているコピー（このファイルと同じ場所にある templates/ 内）を使用します。プロジェクト既存のタスク文書が異なる形式に従っている場合は、その形式に合わせます。ただし、以下の必須セクションは保持します。

実行ティアの指針

タスク文書の Recommended Tier を使用します。

ティア	使用する状況
fast	既存のパターンに沿った、小規模でリスクの低い変更。
balanced	通常の機能開発、中程度のリファクタリング、または複数ファイルにまたがる変更。
deep	アーキテクチャ、セキュリティ、データモデル、マイグレーション、リスクの高いリファクタリング、または要件が曖昧な場合。

ティアは後続のエージェント向けの指針です。ティアをモデルや推論設定にどう対応させるか、または対応させるかどうかは、ランタイムアダプターが定義します。

タスクドキュメントの要件

タスクドキュメントには、以下を含める必要があります。

• 概要と要件を明確に記載する
• 対象外の範囲、または変更してはならない境界を明示する
• 変更を提案するファイル
• 実装段階で読み込むべきファイルの、対象を絞ったコードコンテキスト
• 実装手順
• 受け入れ基準
• 検証コマンドまたは検証方法
• Coordination（重複するタスクとファイル、または「該当なし」）
• Open Decisions（各項目を BLOCKING または NON-BLOCKING とするか、「なし」）
• Operator Steps（または「なし：マージで十分」）
• 該当する場合、パッケージング、ドキュメント、アダプター、インストール方法に関わる互換性の確認箇所

受け入れ基準は説明文ではなく、検証項目です。 各項目には、検証に使用するコマンド、クエリ、API 呼び出し、またはブラウザーでの操作、期待される結果、マージ前とデプロイ後のどちらで実行するかを明記します。変更してはならない動作について、少なくとも 1 つの非回帰チェックを含めます。失敗し得るチェックがない項目は、後から受け入れ基準として提示できません。自動化できない場合は、manual と記載し、その理由を明示してください。

ライブ調査に基づくタスクの場合は、実装エージェントが説明文を鵜呑みにせず再検証できるよう、根拠（クエリ、レコード ID、件数、file:line）を含めます。

Code Context には、簡潔なコード抜粋または注記を埋め込みます。無関係なファイル全体を貼り付けないでください。

TASKS.md の更新

TASKS.md が存在しない場合は、テンプレート（「Templates」を参照）に基づいて作成します。

存在する場合は、テンプレートと異なっていても、既存のセクションと列に合わせます。次の例のように、Planned（またはプロジェクトにおける同等のセクション）にタスクを追加します。

| {ID} | {Task} | {Priority} | {Type} | docs/task/{ID}-{task-name}.md | {Date} |

タスクに BLOCKING の未決定事項がある場合は、その旨を行に記載します（「⚠️ 実装前に D1 の決定が必要」）。

引き継ぎ

最後に、以下を記載します。

Task planned: docs/task/{ID}-{task-name}.md
Status: awaiting user review
Blocking decisions: {list or "None"}
Coordinates with: {task IDs or "None"}
Next stage after approval: implement {ID}