speckit-tasks

speckit-tasks

このスキルの内容は、GitHub Spec Kit の公式プロンプトテンプレートに基づいています。

• 上流：https://github.com/github/spec-kit
• ライセンス：MIT License, Copyright GitHub, Inc.（全文は同じディレクトリの LICENSE.txt を参照）
• 適用について：公式テンプレートはスラッシュコマンドを使う場面を想定しています。原文中の $ARGUMENTS は、会話でユーザーが提示したリクエストを指します。 コマンド間の参照（speckit.plan など）は、このスキル体系では同名の speckit-* スキルに対応します。 それ以外の内容は上流と同じで、書き換えていません。

---

ユーザー入力

$ARGUMENTS

ユーザー入力がある場合は、先に進む前に必ずその内容を考慮してください。

実行前の確認事項

タスク生成前に拡張フックを確認する：

• プロジェクトルートに .specify/extensions.yml が存在するか確認します。
• 存在する場合は、そのファイルを読み込み、hooks.before_tasks キーの下にあるエントリーを確認します。
• YAML を解析できない場合、または無効な場合は、黙ってスキップしないでください。パーサーエラーを含めて .specify/extensions.yml を読み込めなかったこと、および、そこに登録されている必須（optional: false）フックを含め、フックを確認できなかったことをユーザーに伝えてから、通常どおり続行してください。
• enabled が明示的に false のフックを除外します。enabled フィールドがないフックは、デフォルトで有効として扱います。
• 残りの各フックについて、condition 式の解釈や評価を試みないでください。
  • フックに condition フィールドがない場合、またはその値が null／空の場合は、実行可能なフックとして扱います。
  • フックに空でない condition が定義されている場合は、そのフックをスキップし、条件の評価は HookExecutor の実装に委ねます。
• 実行可能な各フックについて、optional フラグに基づいて以下を出力します。
  • 任意のフック（optional: true）：

    ## 拡張フック
    
    **任意の事前フック**：{extension}
    コマンド：`/{command}`
    説明：{description}
    
    プロンプト：{prompt}
    実行するには：`/{command}`
    

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

    ## 拡張フック
    
    **自動事前フック**：{extension}
    実行中：`/{command}`
    EXECUTE_COMMAND: {command}
    
    アウトラインに進む前に、フックコマンドの結果を待ってください。
    

    上記のブロックを出力した後、続行する前にフックを実際に呼び出し、完了するまで待つ必要があります。エージェント自身がこのセッションでコマンドを実行するのと同じ方法で実行してください（呼び出し方法は、上記に表示されているリテラルな {command} の ID と異なる場合があります。たとえば、スキルモードのエージェントでは /skill:speckit-... または $speckit-... のように実行します）。ブロックを出力するだけでは、フックを実行したことにはなりません。
• フックが登録されていない場合、または .specify/extensions.yml が存在しない場合は、何もせずにスキップします。

概要

1. セットアップ：リポジトリのルートから {SCRIPT} を実行し、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（テストシナリオ）
   • 存在する場合：プロジェクトの原則とガバナンス上の制約について、/memory/constitution.md を読み込みます
   • 注：すべてのプロジェクトにすべてのドキュメントがあるわけではありません。利用可能なドキュメントに基づいてタスクを生成します。

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

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

4. tasks.md の生成：構成には TASKS_TEMPLATE_CONTENT（上記の JSON 出力から）を使用します。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 の実装に任せます。
• 実行可能な各フックについて、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、ラベル、ファイルパス）に従っていることを確認します。

タスク生成のコンテキスト：{ARGS}

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 の範囲をユーザーに報告して完了を伝えた