speckit-tasks

ユーザー入力

$ARGUMENTS

（空でない場合は）先に進む前に、必ずユーザー入力を考慮してください。

実行前の確認事項

タスクの生成前に拡張フックを確認してください：

• プロジェクトのルートに .specify/extensions.yml が存在するか確認します。
• 存在する場合は内容を読み、hooks.before_tasks キーの下にあるエントリを確認します。
• YAML を解析できない場合、または無効な場合は、黙ってスキップしてはいけません。.specify/extensions.yml を読み込めなかったこと（パーサーエラーを含む）と、そこに登録されている必須（optional: false）フックも含め、フックを確認していないことをユーザーに伝えてから、通常どおり続行します。
• enabled が明示的に false のフックは除外します。enabled フィールドがないフックは、デフォルトで有効として扱います。
• 残りの各フックについて、condition 式の解釈や評価は試みないでください。
  • フックに condition フィールドがない場合、またはその値が null／空の場合、実行可能なフックとして扱います。
  • 空でない condition が定義されている場合は、そのフックをスキップし、条件の評価は HookExecutor の実装に委ねます。
• フックのコマンド名からコマンド呼び出しを構成する際は、ドット（.）をハイフンに置き換えます。たとえば、speckit.git.commit → /speckit-git-commit です。
• 実行可能な各フックについて、optional の値に応じて以下を出力します。

  • 任意フック（optional: true）：

    ## Extension Hooks
    
    **Optional Pre-Hook**: {extension}
    Command: `/{command}`
    Description: {description}
    
    Prompt: {prompt}
    To execute: `/{command}`
    

  • 必須フック（optional: false）：

    ## Extension Hooks
    
    **Automatic Pre-Hook**: {extension}
    Executing: `/{command}`
    EXECUTE_COMMAND: {command}
    
    Wait for the result of the hook command before proceeding to the Outline.
    

    上記のブロックを出力した後、続行する前にフックを実際に呼び出し、完了を待つ必要があります。自分でこのエージェント／セッション内でコマンドを実行する場合と同じ方法で実行します（呼び出し方法は、表示されている {command} の ID と異なる場合があります。たとえば、スキルモードのエージェントでは /skill:speckit-... や $speckit-... を使用します）。ブロックを出力するだけでは、フックを実行したことにはなりません。

• フックが登録されていない場合、または .specify/extensions.yml が存在しない場合は、何もせずにスキップします。

概要

1. セットアップ：リポジトリのルートから .specify/scripts/bash/setup-tasks.sh --json を実行し、FEATURE_DIR、TASKS_TEMPLATE_CONTENT、TASKS_TEMPLATE、AVAILABLE_DOCS のリストを解析します。指定される場合、FEATURE_DIR と TASKS_TEMPLATE は絶対パスである必要があります。AVAILABLE_DOCS は、FEATURE_DIR 配下で利用可能なドキュメント名／相対パスのリストです（例：research.md、contracts/）。「I'm Groot」のように引数にシングルクォートが含まれる場合は、エスケープ構文を使用します。例：'I'''m Groot'（または可能であればダブルクォートを使用します："I'm Groot"）。

2. 設計ドキュメントの読み込み：FEATURE_DIR から読み込みます。

   • 必須：plan.md（技術スタック、ライブラリ、構成）、spec.md（優先度付きユーザーストーリー）
   • 任意：data-model.md（エンティティ）、contracts/（インターフェース契約）、research.md（決定事項）、quickstart.md（テストシナリオ）
   • 存在する場合：.specify/memory/constitution.md を読み込み、プロジェクトの原則とガバナンス上の制約を確認します
   • 注：すべてのプロジェクトにすべてのドキュメントがあるわけではありません。利用可能なドキュメントに基づいてタスクを生成します。

3. タスク生成ワークフローの実行：

   • plan.md を読み込み、技術スタック、ライブラリ、プロジェクト構成を抽出します
   • spec.md を読み込み、優先度（P1、P2、P3 など）付きのユーザーストーリーを抽出します
   • data-model.md が存在する場合：エンティティを抽出し、ユーザーストーリーに対応付けます
   • contracts/ が存在する場合：インターフェース契約をユーザーストーリーに対応付けます
   • research.md が存在する場合：セットアップタスクに必要な決定事項を抽出します
   • ユーザーストーリーごとに整理したタスクを生成します（以下のタスク生成ルールを参照）
   • ユーザーストーリーの完了順を示す依存関係グラフを生成します
   • ユーザーストーリーごとに並列実行の例を作成します
   • タスクの完全性を検証します（各ユーザーストーリーに必要なタスクがすべて含まれ、個別にテスト可能であること）

4. tasks.md の生成：上記の JSON 出力に含まれる TASKS_TEMPLATE_CONTENT を構成として使用します。TASKS_TEMPLATE_CONTENT を省略する旧バージョンのセットアップスクリプトとの互換性が必要な場合は、代わりに TASKS_TEMPLATE を読み込みます。以下を記入します。

   • plan.md に基づく正しい機能名
   • フェーズ 1：セットアップタスク（プロジェクトの初期化）
   • フェーズ 2：基盤タスク（すべてのユーザーストーリーに必要なブロッキング前提条件）
   • フェーズ 3 以降：ユーザーストーリーごとに 1 フェーズ（spec.md の優先順位順）
   • 各フェーズに含める内容：ストーリーの目標、独立したテスト基準、テスト（要求されている場合）、実装タスク
   • 最終フェーズ：仕上げと横断的な懸案事項
   • すべてのタスクは厳密なチェックリスト形式に従う必要があります（以下のタスク生成ルールを参照）
   • 各タスクの明確なファイルパス
   • ストーリーの完了順を示す依存関係セクション
   • ストーリーごとの並列実行の例
   • 実装戦略セクション（MVP を最初に、段階的に提供）

必須のタスク実行後フック

ユーザーに完了を報告する前に、このセクションを必ず完了してください。

プロジェクトのルートに .specify/extensions.yml が存在するか確認します。

• 存在しない場合、または hooks.after_tasks にフックが登録されていない場合は、「完了レポート」に進みます。
• 存在する場合は読み込み、hooks.after_tasks キーの下にある項目を確認します。
• YAML を解析できない、または無効な場合は、何も通知せずにスキップしてはいけません。.specify/extensions.yml を読み込めなかったこと（パーサーエラーを含む）と、そこに登録された必須（optional: false）フックも含めてフックを確認できなかったことをユーザーに伝えてから、「完了レポート」に進みます。
• enabled が明示的に false のフックは除外します。enabled フィールドがないフックは、デフォルトで有効として扱います。
• 残りの各フックについて、フックの condition 式を解釈または評価しようとしてはいけません。
  • フックに condition フィールドがない場合、またはその値が null／空の場合、実行可能なフックとして扱います。
  • フックに空でない condition が定義されている場合は、そのフックをスキップし、条件の評価は HookExecutor の実装に委ねます。
• フックのコマンド名からコマンド呼び出しを組み立てる際は、ドット（.）をハイフンに置き換えます。たとえば、speckit.git.commit → /speckit-git-commit です。
• 実行可能なフックごとに、optional フラグに基づいて次の内容を出力します。

  • 必須フック（optional: false）— 必須フックごとに、必ず EXECUTE_COMMAND: を出力してください。

    ## Extension Hooks
    
    **Automatic Hook**: {extension}
    Executing: `/{command}`
    EXECUTE_COMMAND: {command}
    

    上記のブロックを出力した後、フックを実際に呼び出し、処理が完了するまで待ってから続行してください。このエージェント／セッションで自分自身がコマンドを実行するのと同じ方法で実行します（呼び出し方法は、表示された {command} ID の表記と異なる場合があります。たとえば、スキルモードのエージェントでは /skill:speckit-... や $speckit-... のようになります）。ブロックを出力しただけではフックは実行されません。

  • 任意のフック（optional: true）：

    ## Extension Hooks
    
    **Optional Hook**: {extension}
    Command: `/{command}`
    Description: {description}
    
    Prompt: {prompt}
    To execute: `/{command}`
    

完了レポート

生成した tasks.md のパスと以下の要約を出力します。

• タスクの総数
• ユーザーストーリーごとのタスク数
• 特定された並行作業の機会
• 各ストーリーの独立したテスト基準
• 推奨される MVP の範囲（通常はユーザーストーリー 1 のみ）
• 形式の検証：すべてのタスクがチェックリスト形式（チェックボックス、ID、ラベル、ファイルパス）に従っていることを確認します。

タスク生成のコンテキスト：$ARGUMENTS

tasks.md はすぐに実行に移せる内容にしてください。各タスクは、LLM が追加のコンテキストなしで完了できる程度に具体的である必要があります。

タスク生成ルール

重要：独立した実装とテストを可能にするため、タスクは必ずユーザーストーリーごとに整理してください。

テストは任意です：機能仕様で明示的に求められている場合、またはユーザーが TDD アプローチを希望している場合に限り、テストタスクを生成してください。

チェックリスト形式（必須）

すべてのタスクは、必ず次の形式に従ってください。

- [ ] [TaskID] [P?] [Story?] Description with file path

形式の構成要素:

1. チェックボックス：必ず - [ ] で始めます（Markdown のチェックボックス）。
2. タスク ID：実行順に連番を付けます（T001、T002、T003...）。
3. [P] マーカー：タスクが並列実行可能な場合にのみ含めます（異なるファイルを対象とし、未完了タスクへの依存がない場合）。
4. [Story] ラベル：ユーザーストーリーのフェーズに属するタスクにのみ必須です。
   • 形式：[US1]、[US2]、[US3] など（spec.md のユーザーストーリーに対応します）。
   • セットアップフェーズ：ストーリーラベルなし
   • 基盤フェーズ：ストーリーラベルなし
   • ユーザーストーリーのフェーズ：ストーリーラベル必須
   • 仕上げフェーズ：ストーリーラベルなし
5. 説明：正確なファイルパスを含め、実行内容を明確に記述します。

例:

• ✅ 正しい：- [ ] T001 実装計画に沿ってプロジェクト構成を作成する
• ✅ 正しい：- [ ] T005 [P] src/middleware/auth.py に認証ミドルウェアを実装する
• ✅ 正しい：- [ ] T012 [P] [US1] src/models/user.py に User モデルを作成する
• ✅ 正しい：- [ ] T014 [US1] src/services/user_service.py に UserService を実装する
• ❌ 誤り：- [ ] User モデルを作成する（ID とストーリーラベルがありません）
• ❌ 誤り：T001 [US1] モデルを作成する（チェックボックスがありません）
• ❌ 誤り：- [ ] [US1] User モデルを作成する（タスク ID がありません）
• ❌ 誤り：- [ ] T001 [US1] モデルを作成する（ファイルパスがありません）

タスクの整理

1. ユーザーストーリー（spec.md）に基づく — 主な整理基準：

   • 各ユーザーストーリー（P1、P2、P3...）に専用のフェーズを設けます。
   • 関連するすべてのコンポーネントを、それぞれのストーリーに対応付けます。
     • そのストーリーに必要なモデル
     • そのストーリーに必要なサービス
     • そのストーリーに必要なインターフェース／UI
     • テストが要求されている場合：そのストーリーに固有のテスト
   • ストーリー間の依存関係を明記します（ほとんどのストーリーは独立しているはずです）。

2. コントラクトに基づく：

   • 各インターフェースコントラクトを、それが対応するユーザーストーリーに割り当てます。
   • テストが要求されている場合：各インターフェースコントラクトについて、そのストーリーのフェーズで実装する前に、コントラクトテストのタスクを [P] 付きで作成します。

3. データモデルに基づく：

   • 各エンティティを、それを必要とするユーザーストーリーに割り当てます。
   • エンティティが複数のストーリーで使われる場合：最も早いストーリーのフェーズ、またはセットアップフェーズに配置します。
   • リレーションシップ：適切なストーリーフェーズにサービスレイヤーのタスクを配置します。
   • data-model.md で制約（最大長、NULL 許可／必須、列挙値、検証ルール）が指定されているフィールドごとに、実装時の判断に委ねないよう、制約をタスクの説明に原文のまま記載します。

4. セットアップ／インフラストラクチャに基づく：

   • 共有インフラストラクチャ：セットアップフェーズ（フェーズ 1）に配置します。
   • 基盤となるタスク／ブロッキングタスク：基盤フェーズ（フェーズ 2）に配置します。
   • ストーリー固有のセットアップ：そのストーリーのフェーズ内に配置します。

フェーズ構成

• フェーズ 1：セットアップ（プロジェクトの初期化）
• フェーズ 2：基盤（ブロッキングとなる前提条件 — ユーザーストーリーに着手する前に必ず完了してください）
• フェーズ 3 以降：優先順位（P1、P2、P3...）に沿ったユーザーストーリー
  • 各ストーリー内の順序：テスト（要求されている場合）→ モデル → サービス → エンドポイント → 統合
  • 各フェーズは、独立してテストできる完結した単位とします。
• 最終フェーズ：仕上げと横断的な懸案事項

完了条件

• すべてのフェーズ、タスク ID、ファイルパスを含む tasks.md を生成した
• 上記の必須実行後フックのルールに従い、拡張フックを実行またはスキップした
• タスク数、ストーリーの内訳、MVP の範囲をユーザーに報告して完了を伝えた