タスク取得 (Get Tasks)
概要
get-tasks は、承認済みのPRDを実行可能なタスクセットに変換します。各タスクは独自のファイルに書き出され、1回の集中セッションに適したサイズに調整され、依存関係に基づいて順序付けられ、受け入れ基準、検証手順、ブロッキングリスト、ロールバック手順が含まれています。
これが独立したスキルとして存在する理由：PRDは計画ではありません。PRDはシステムが何をし、なぜそれをするかを述べます。作業の順序、並行して構築できるもの、リスクの高い部分、またはスライスが完了したことを証明する方法については何も語りません。PRDをそのままコードに変換すると、英雄的な1回の変更か、途中で壊れる恣意的な順序のいずれかになります。
get-tasks は不足しているレイヤーを提供します。PRDを読み取り、実際の依存関係構造をマッピングし、作業を垂直スライスに分割し、各スライスをエージェント（または人間）がPRD全体を再読せずに取り組める独立した成果物として書き出します。
このスキルは3つの源泉から引き出されています：
- 依存関係優先の分解と垂直スライシング — 依存関係グラフを構築し、水平ではなく垂直にスライスし、各タスクのサイズを調整し、チェックポイントを配置します。これが順序を正しくするものです。
- 検証駆動の実行 — すべてのタスクは、単に「テストが通る」だけでなく、複数の検証タイプにわたってどのように検証されるかを宣言し、ステップが失敗した場合の再計画手順を保持します。
- ブロッキングエッジとトレーサーバレット — 各タスクは何が自分をブロックしているかを明示的に述べるため、ブロッカーが完了したタスクはすぐに開始できます。
出力はタスクファイルのディレクトリです：tasks/<name>/task-01.md、task-02.md など、依存関係順に番号が付けられ、さらに tasks/<name>/plan.md がそれらをインデックス化します。ブロッカータスクは小さい番号を取得します。
このスキルの範囲
get-tasks は意図的に包括的です。いくつかのより狭いスキルがそれぞれ部分的に行っていたことを吸収し、ユーザーが承認済みPRDから追跡可能で実行可能な計画に至るまでに1つのスキルだけを必要とするようにします。ここにあるすべてはその単一のジョブに関連しています：
| 関心事 | 処理場所 |
|---|---|
| PRDの読み取りとコミットメントの抽出 | フェーズ1 |
| 依存関係構造と順序付け | フェーズ2 |
| 垂直スライシングとトレーサーバレット | フェーズ3 |
| ワイドリファクタ（拡張、移行、縮小） | フェーズ3 |
| タスクごとの仕様 | フェーズ4 |
| サイジングと分割ルール | フェーズ5 |
| チェックポイントとゲート | フェーズ5 |
| 並列化分類 | 並列化分類法 |
| 人間可読な計画サマリー、リスク、決定事項 | フェーズ6 |
| トラッカー vs ファイルターゲット | タスクリストターゲット |
| 書き込み前のユーザー承認 | フェーズ7 |
| 成果物の書き込み、同期、検証 | フェーズ8 |
| 障害と再計画の処理 | タスク失敗時の再計画 |
設計上、長くなっています。長さが重要です：これらのいずれかを暗黙のままにする分解は、完成しているように見えて実際には完成していないタスクを生み出します。テンプレートに飛ばずに読みたくなったら、代わりにフェーズ2、3、5を読んでください — そこが分解が実際に失敗する場所です。
このスキルがしないこと：コードを書かない、タスクを実行しない、PRDを置き換えない。1つのドキュメントを一連のドキュメントに変換します。
使用するタイミング
以下の場合にこのスキルを使用します：
- PRD、仕様、または要件文書が存在し、作業を実行可能なタスクに変換する必要がある場合
- ユーザーが「get tasks」「breakdown PRD」「pecah jadi task」「bikin task list」「これをタスクに変換して」と言った場合
- タスクが大きすぎて開始できず、分解が必要だと感じられる場合
- スコープを見積もったり、作業を順序付けたり、並行して実行できるものを見つける必要がある場合
- 数ファイル以上に触れるものを実装しようとしていて、タスクリストが存在しない場合
使用すべきでない場合：
- PRDがまだ存在しない場合 — 最初に
get-prdを実行し、その後戻ってくる - 変更がどの尺度でも単一のタスクである場合（1ファイル、1つの明白な編集） — 単に実行する
tasks/に完全なタスク分解がすでに存在し、実装の準備ができている場合 — タスクを順番に実行する
プロセス
get-tasks は9つのフェーズで実行されます。各フェーズには終了条件があります。終了条件が満たされていないフェーズに進まないでください。
0. PRDの特定 -> どのドキュメントがソースか？
1. 読み取りと抽出 -> PRDは私たちに何を約束させているか？
2. 依存関係グラフ -> 何が何に依存しているか？
3. 垂直スライス -> トレーサーバレット、水平レイヤーではない
4. 各タスクの書き込み -> タスクごとに1ファイル、完全に指定
5. 順序付け、サイズ調整、チェックポイント -> シーケンス、サイズ、検証ゲート
6. 計画ドキュメントの書き込み -> タスクをインデックス化する人間可読なサマリー
7. ユーザーへの確認 -> 粒度、ブロッキングエッジ、マージまたは分割
8. 書き込みと検証 -> ディスク上のファイル、同期されたTODO、検証がグリーン
タスク分解の普遍的原則
- 自然言語のペーシング： 分解と会話によるサマリーは、ユーザーが話す言語（インドネシア語または英語）で提示し、ファイル名、git用語、コードトークンは標準のままにする（
task-01.md、branch、commit、TDD）。 - 自律実行準備完了： 生成された各タスクファイル（
tasks/<feature>/task-*.md）は完全に自己完結していなければなりません。どのコーディングエージェントも、その単一のタスクファイルだけを読み、どのファイルを編集すべきか、どのテストを実行すべきか、どの完了条件を満たす必要があるかを推測せずに知ることができる必要があります。 - 水平レイヤーより垂直スライス： 単独でエンドツーエンドで検証できない場合、「バックエンドのセットアップ」や「フロントエンドのセットアップ」だけのタスクを決して作成しないでください。垂直にスライスしてください（例：「SKUエンドポイントの保存とクエリ（UIトリガー付き）」）。各タスクがテスト可能な価値を提供するようにします。
計画は読み取り専用です。 フェーズ0から7まではドキュメントと質問を生成し、コードは生成しません。これらのフェーズ中はソースファイルを作成、編集、削除しないでください。tasks/ の下にタスクファイルを書き込むことだけが、ユーザーの承認前に行える唯一のファイルシステム変更です。作業を分解中にバグを修正したり、関数を追加していることに気づいたら、やめてください：それは承認後の実装に属し、まだ書いていないタスクに属します。
フェーズ0: PRDの特定
他の何をする前に、ソースドキュメントを見つけます。
- まず規約に従う。
get-prdはdocs/prd/<name>.mdに保存します。最初にそこを探します。 - 次に広く検索する。
docs/prd/が空の場合、ユーザーが名前を指定したPRDを探します。Issue本文や貼り付けられた要件文書も受け入れます — スキルはフォーマットに縛られず、フェーズ1での抽出のみがPRDセクション名を前提とします。 - 候補が複数ある場合、推測しないでください。それらをリストし、どれがこの作業を統治するか尋ねてください。
- 存在しない場合、停止してその旨を伝えてください。要件を発明しないでください。ユーザーをフルインタビューからPRDへのパスである
get-prdに誘導してください。
作業中の正確なパスを記録してください。後のすべてのフェーズがそれを参照します。
マルチモジュールイニシアチブ の場合、PRDがモジュールIDごとに分割されている場合（docs/prd/identity.md、docs/prd/billing.md）、この分解がどのモジュールをカバーするか確認してください。モジュールごとに1つの分解、能力マップが宣言したビルド順序で行います。
終了条件： 単一のソースドキュメントが特定され、そのパスが記録されていること。
フェーズ1: 読み取りと抽出
PRDを完全に読みます。次に、分解を駆動する内容を明示的に抽出します：
| PRDセクション | そこから抽出する内容 |
|---|---|
| 目的 (Objective) | すべてのタスクが最終的に提供するエンド状態 |
| ユーザーストーリー (User Stories) | 機能しなければならない観察可能な動作、候補となる受け入れ基準 |
| 技術的決定 (Technical Decisions) | モジュール、インターフェース、スキーマ変更、契約 — これらがタスク間の実際の境界を定義する |
| プロジェクト構造 (Project Structure) | 成果物が配置される場所、「触れる可能性のあるファイル」を制約する |
| コマンド (Commands) | 各タスクが引用する具体的な検証コマンド |
| テスト戦略 (Testing Strategy) | ここで良いテストとは何か、テストが属する場所 |
| 境界 (Boundaries) | 常に (Always) / 最初に尋ねる (Ask First) / 決してしない (Never) — Never 項目はすべてのタスクのハード制約になる |
| スコープ外 (Out of Scope) | 明示的な非目標；ここにあるものはタスクにならない |
| 成功基準 (Success Criteria) | 最終ゲート；最後のチェックポイントがこれに対して検証する |
ルール：
- まだスライスを始めないでください。 最初に抽出、次に分解。読みながらスライスすると、たまたま文書を読んだ順序によって形作られたタスクが生成されます。
- 曖昧な項目を確認可能なステートメントに変換する。 PRDが「ダッシュボードは高速であるべき」と言っている場合、タスクの受け入れ基準は数値です。PRDが数値を与えていない場合、静かに選択するのではなく、ブロッカーとして表面化させてください。
- ギャップをフラグする。 必要なセクションが欠落しているか空の場合、それを名前付けてください。テスト戦略が欠落している場合、すべてのタスクの検証ブロックは後で発明されることになります；今すぐ提起してください。
- 要件を発明しないでください。 PRDがそれを言っていなければ、それはタスクではありません。
終了条件： 抽出テーブルが入力され、ギャップがユーザーに提起されていること。
フェーズ2: 依存関係グラフのマッピング
単一のタスクを書く前に、何が何に依存しているかをマッピングします。これは順序を決定し、最も高価な種類のミス（プロデューサーが存在する前にコンシューマーを構築すること）を防ぐフェーズです。
グラフを描きます。具体的に、抽象的にではなく：
データベーススキーマ
|
+-- APIモデルと型
| |
| +-- APIエンドポイント
| | |
| | +-- フロントエンドAPIクライアント
| | |
| | +-- UIコンポーネント
| |
| +-- 検証ロジック
|
+-- シードデータとマイグレーション
ルール：
- エッジはプロデューサーからコンシューマーへ向かう。 矢印は「ターゲットが先にソースを必要とする」ことを意味します。
- 循環なし。 もし2つのものが互いに必要とする場合、それらは1つのタスクであるか、それらの間のインターフェースを最初に独自のタスクとして定義する必要があります。
- インターフェースは境界である。 2つのタスクが契約（型、エンドポイント形状、スキーマ）で出会う場合、契約をより早いタスクで定義し、後のタスクで消費します。両方のタスクが独立してそれを発明させることは決してしないでください。
- フロンティアを見つける。 フロンティアとは、すべてのブロッカーが完了したすべてのタスクです。それは今すぐ開始できるものです。線形チェーンの場合、フロンティアは1タスク幅です；広いプロジェクトの場合、複数になることがあります。
- 並行処理の機会とハードなシーケンスを名前付ける。 独立したスライスは並行して実行できます。マイグレーション、共有状態の変更、および同じ契約に触れるものはすべて順次でなければなりません。
終了条件： 明確なフロンティアと循環なしの依存関係グラフが存在すること。
フェーズ3: 垂直にスライスする
作業をトレーサーバレットにカットします：機能が必要とするすべてのレイヤーを通る狭くても完全なパスです。
水平スライシングはデフォルトのミスです。 きれいに見えますが、最後のタスクまで実行可能なものは何も生成しません：
悪い例（水平）：
タスク1: データベーススキーマ全体を構築する
タスク2: すべてのAPIエンドポイントを構築する
タスク3: すべてのUIコンポーネントを構築する
タスク4: すべてを接続する
タスク3の終了時点で、何も機能しません。誰も何もデモできません。タスク1での誤った仮定はタスク4で発見されます。
垂直スライシングはすべてのステップで動作するソフトウェアを生成します：
良い例（垂直）：
タスク1: ユーザーはアカウントを作成できる（登録用のスキーマ + API + UI）
タスク2: ユーザーはログインできる（認証スキーマ + API + UI）
タスク3: ユーザーはタスクを作成できる（タスクスキーマ + API + 作成用UI）
タスク4: ユーザーはタスクリストを表示できる（クエリ + API + リスト表示用UI）
良いスライスのルール：
- 動作が必要とするすべてのレイヤーを貫く — データ、ロジック、インターフェース、テスト。
- それ自体でデモ可能または検証可能である。 動作を確認する方法を説明できない場合、それはスライスではありません。
- 1回の集中セッションに収まる — おおよそ1つの新しいコンテキストウィンドウ。
- 構造ではなく動作を提供する。 「usersテーブルを追加する」はスライスではありません；「ユーザーが登録できる」はスライスです。
ワイドリファクタは例外です。 ワイドリファクタとは、1つの機械的な変更（列名の変更、共有シンボルの型変更）であり、その影響範囲がコードベース全体に広がるため、垂直スライスではグリーンになりません。トレーサーバレットに無理やり押し込まないでください。拡張、移行、縮小 としてシーケンスします：
- 拡張 (Expand) — 古いものと並べて新しい形式を追加し、何も壊さないようにします。
- 移行 (Migrate) — 呼び出しサイトを影響範囲（パッケージごと、ディレクトリごと）でバッチに分けて移動します。各バッチは、古い形式がまだ存在するため、ビルドをバッチ間でグリーンに保ちながら、拡張によってブロックされる独自のタスクです。
- 縮小 (Contract) — 呼び出し元がなくなったら古い形式を削除します。すべての移行バッチによってブロックされるタスクで行います。
バッチでさえ単独でグリーンを保てない場合でも、同じシーケンスを維持しますが、それらがすべて最終的な統合および検証タスクをブロックする共有の統合ブランチを持たせ、グリーンが保証されるようにします。
終了条件： すべての作業単位が正確に1つのタスクに属し、すべてのタスクが垂直スライスまたは宣言されたワイドリファクタステップであること。
フェーズ4: 各タスクの書き込み
各タスクを独自のファイルとして書き込みます。常にタスクごとに1ファイル — すべてのタスクを1つの結合ドキュメントにしないでください。
出力パス： tasks/<name>/task-NN.md。ここで <name> はPRDの名前と一致します（したがって docs/prd/billing.md のPRDは tasks/billing/task-01.md を生成します）。依存関係順に 01 から番号を付けます — ブロッカーは小さい番号を取得します。
タスクファイルテンプレート：
# タスク NN: <短い説明的なタイトル>
**ソース:** docs/prd/<name>.md — <このタスクが実装するPRDセクション>
**構築するもの:** このタスクが動作させるエンドツーエンドの動作。ユーザーの視点から。レイヤーごとの実装リストではありません。ユーザーまたは呼び出し元が観察できる動作として説明できない場合、タスクを再構成してください。
## 受け入れ基準
- [ ] <具体的でテスト可能な条件>
- [ ] <具体的でテスト可能な条件>
すべての基準は、タスクを書いていない人でもチェック可能でなければなりません。「正しく動作する」は基準ではありません。「ユーザーがメールとパスワードで登録でき、ダッシュボードにリダイレクトされる」は基準です。
## 検証
- [ ] テストが通る: <リポジトリの集中テストコマンド、または最初に書く新しいテスト>
- [ ] ビルドが成功する: <リポジトリのビルドコマンド>
- [ ] 出力が一致する: <存在すべき期待されるパターンまたは成果物>
- [ ] リグレッションなし: <フルスイートまたは関連サブセット>
- [ ] 品質とセキュリティ: <入力検証、認証境界、以下に従う…>
[翻訳のため切り詰められました]