create-tasks

タスクの作成

会話に参加していなかったエンジニアでも、事前知識がなく、質問をしなくてもタスクを実装できるように、多くのコンテキストを含む、明確に定義されたタスクを作成します。

タスクは、スキルを適用するプロジェクトのツールとドキュメントの規約に従って作成してください。規約が明確でない場合は、ユーザーに確認してから文書化してください。

エンジニアが必要とする情報

すべてのタスクに、次の内容を記載する必要があります。

• 何を構築するのか（成果物）
• なぜ重要なのか（背景）
• 従うべき重要な判断と原則
• 受け入れ基準
• 依存関係
• 関連するコードやパターン
• 動作の検証方法

タスクを作成する前に：まずスライスする

🚨 サイズを検証せずにタスクを作成してはいけません。 PRD の成果物が自動的にタスクになるわけではありません。分割が必要なエピックかもしれません。

Example Mapping による発見

🚨 PRD の箇条書きをそのままコピーしてはいけません。 Example Mapping を使って、実行可能な仕様に変換してください。

カード	実施内容
🟡 ストーリー	成果物を具体的な一文で示します
🔵 ルール	すべてのビジネスルールや制約を列挙します（タスクあたり最大 3～4 件）
🟢 例	各ルールについて、正常系、エッジケース、エラーケースを示します
🔴 質問	不明点を明らかにし、事前に解決するか、調査タスクを作成します

例（🟢）が受け入れ基準になります。 Given-When-Then 形式で記述してください。

Given [context/precondition]
When [action/trigger]
Then [expected outcome]

エッジケースのチェックリスト — 各ルールについて、次の点を体系的に検討します。

カテゴリー	確認項目
入力	空、null、空白、境界値、不正な形式、特殊文字、Unicode、長すぎる入力
状態	同時更新、競合状態、不正な順序、すでに存在する場合、存在しない場合
エラー	ネットワーク障害、タイムアウト、一部の処理の失敗、権限の不備、クォータ超過

例： PRD に「ユーザーは商品を検索できる」と記載されている場合

特定されたルール：（1）タイトルで検索、（2）ページネーション、（3）空の状態

ルール 1 だけでも、エッジケースを検討すると次のようになります。

• 商品が存在する場合 → 検索すると → 結果が返る（正常系）
• 一致する商品がない場合 → 検索すると → 空の結果が返る
• 検索語が空の場合 → 送信すると → 検証エラーになるのか、すべての商品が表示されるのか？（🔴 質問！）
• 検索語に特殊文字が含まれる場合 → 検索すると → 安全に処理される

分割の兆候（タスクが大きすぎる場合）

次のいずれかに当てはまる場合は、作業を止めて分割してください。

• ❌ 具体的で行動を示すタイトルを付けられない
• ❌ 1 日を超える作業になる
• ❌ タイトルに「と」が必要、または複数の項目が列挙されている
• ❌ 受け入れ基準が複数のまとまりに分かれている
• ❌ 水平方向に分割されている（まずデータベース全体、次に API 全体、最後に UI 全体）
• ❌ PRD に「完全な実装」または「完全なシステム」と記載されている

SPIDR による分割手法

分割が必要な場合は、次の手法を使ってください。

手法	分割基準	例
Paths（パス）	ユーザーフローの違い	「カードで支払う」と「PayPal で支払う」
Interfaces（インターフェース）	UI やプラットフォームの違い	「デスクトップ検索」と「モバイル検索」
Data（データ）	データの種類の違い	「画像をアップロードする」と「動画をアップロードする」
Rules（ルール）	ビジネスルールの違い	「基本的な検証」と「プレミアム検証」
Spikes（調査）	不明な領域	「決済 API を調査する」を「決済を実装する」より先に行う

垂直スライスのみ

すべてのタスクは垂直スライスにする必要があります。つまり、特定の一つのことを実現するために必要なすべてのレイヤーを横断して分割します。

✅ VERTICAL (correct):
"Add search by title" → touches UI + API + DB for ONE search type

❌ HORIZONTAL (wrong):
"Build search UI" → "Build search API" → "Build search DB"

タスクの命名

形式

[アクション動詞] [具体的な対象] [成果／制約]

良い名前の例

• 「商品検索に価格帯フィルターを追加する」
• 「メールアドレスの検証機能を備えた POST /api/users エンドポイントを実装する」
• 「ホームページに商品レコメンデーションを表示する」
• 「取引履歴の CSV エクスポートを有効にする」
• 「チェックアウトフォームの必須項目を検証する」

拒否すべきパターン

🚨 これらはタスクではなくエピックを示すため、絶対に使わないでください。

パターン	不適切な理由
"Full implementation of X"	タスクを装ったエピックです
"Build the X system"	抽象的すぎて、具体的な成果物がありません
"Complete X feature"	スコープが定義されていません
"Implement X"（単独）	具体性が不足しています
"X and Y"	2つのタスクがまとめられています
"Set up X infrastructure"	水平スライスです

これらのいずれかを書きそうになったら、作業を止めて SPIDR を適用してください。

タスクサイズの検証（INVEST）

すべてのタスクは、作成前に INVEST を満たす必要があります。

基準	質問	満たさない場合は分割
Independent（独立性）	単独で価値を提供できますか？	未完了の他のタスクに依存している
Negotiable（交渉可能性）	スコープについて話し合えますか？	融通が利かず、すべてを行うか何もしないかの二択
Valuable（価値）	ユーザー／ステークホルダーにメリットがありますか？	技術的なメリットしかない
Estimable（見積もり可能性）	自信を持って規模を見積もれますか？	「うーん……3日くらい？」
Small（小規模）	1日以内に収まりますか？	1日を超える
Testable（テスト可能性）	具体的な受け入れ基準がありますか？	基準が曖昧、または存在しない

厳格な制限

• 作業は最大1日 — それ以上かかる場合は分割してください
• 垂直スライスにする — 1つの対象について、すべてのレイヤーにまたがる必要があります
• デモ可能にする — 完了時に、動作を実演できる必要があります

タスクテンプレート

## Deliverable: [What user/stakeholder sees]

### Context
[Where this came from and why it matters. PRD reference, bug report, conversation summary—whatever helps engineer understand WHY. You MUST provide the specific file path or URL for any referenced files like a PRD of bug report - don't assume the engineer knows where things are stored]

### Key Decisions and principles
- [Decision/Principle] — [rationale]

### Delivers
[Specific outcome in user terms]

### Acceptance Criteria
- Given [context] When [action] Then [outcome]

### Dependencies
- [What must exist first]

### Related Code
- `path/to/file` — [what pattern/code to use]

### Verification
[Specific commands/tests that prove it works]

プロセス

1. まずスライスする — Example Mapping を適用します。タスクに3〜4個を超えるルールがある場合や、分割の兆候がある場合は、SPIDR を使って細分化します。
2. 受け入れ基準を見つける — 各ルールについて、チェックリストを使って正常系、エッジケース、エラーケースを作成します。Given-When-Then 形式で記述します。不明点を明らかにします。
3. 名前を付ける — 具体的で行動を示すタイトルを付けます。付けられない場合は、タスクが十分に明確ではありません。
4. サイズを検証する — INVEST を満たす必要があります。最大1日です。垂直スライスにする必要があります。
5. コンテキストを収集します（PRD、会話、バグ報告などから）
6. 実装に影響する主要な判断事項を特定します
7. コードベース内の関連するコードやパターンを見つけます
8. 検証コマンドを指定します
9. テンプレートを使ってタスクを出力します

チェックポイント

タスクを確定する前に、以下のすべてを確認してください。

確認事項	質問	いいえの場合
サイズ	作業は1日以内ですか？	SPIDR を使って分割する
名前	タイトルは具体的で、行動を示していますか？	定型に沿って書き直す
垂直性	1つの対象について、すべてのレイヤーにまたがっていますか？	垂直スライスとして再構成する
INVEST	6つすべての基準を満たしていますか？	満たしていない基準を修正する
コンテキスト	エンジニアが質問せずに実装できますか？	不足している情報を追加する

🚨 PRD に「full implementation」などと書かれている場合は、必ず分割してください。このようなタスクを作成することは重大な失敗です。