speckit-implement

speckit-implement

このスキルの内容は、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_implement キーの下にあるエントリーを探します。
• 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 と AVAILABLE_DOCS の一覧を解析します。すべてのパスは絶対パスでなければなりません。"I'm Groot" のように引数にシングルクォートが含まれる場合は、エスケープ構文を使用します。例：'I'\''m Groot'（可能であれば、ダブルクォートで "I'm Groot" と指定してもかまいません）。

2. チェックリストの状態を確認する（FEATURE_DIR/checklists/ が存在する場合）：

   • チェックリストのマーカーは読み取り専用のゲートとして扱います。チェックボックスの状態を調べて状況を報告し、必要に応じて続行前に確認を求めます。チェックリストファイルやマーカーは変更してはいけません。

   • checklists/requirements.md は、__SPECKIT_COMMAND_SPECIFY__ と __SPECKIT_COMMAND_CLARIFY__ が管理する組み込みの仕様品質チェックリストです。__SPECKIT_COMMAND_CHECKLIST__ が生成するカスタムチェックリストは、レビュー担当者が管理する要件品質レビュー用の成果物です。

   • カスタムチェックリストでは、[x] はレビュー担当者が要件品質の基準を満たしていると判断したことを意味します。実装作業が完了したという意味ではありません。

   • checklists/ ディレクトリ内のすべてのチェックリストファイルを調べます。

   • 各チェックリストについて、次の項目を数えます。

     • 項目の合計：- [ ]、- [X]、または - [x] に一致するすべての行
     • チェック済み項目：- [X] または - [x] に一致する行
     • 未チェック項目：- [ ] に一致する行

   • 次のステータステーブルを作成します。

     | チェックリスト | 合計 | チェック済み | 未チェック | ステータス |
     |-----------|-------|---------|-----------|--------|
     | ux.md     | 12    | 12      | 0         | ✓ PASS |
     | test.md   | 8     | 5       | 3         | ✗ FAIL |
     | security.md | 6   | 6       | 0         | ✓ PASS |
     

   • 全体のステータスを判定します：

     • PASS：すべてのチェックリストに未チェック項目がありません
     • FAIL：1 つ以上のチェックリストに未チェック項目があります

   • 未チェック項目があるチェックリストがある場合：

     • 未チェック項目の数を含む表を表示します
     • 停止して、次のように質問します：「未チェック項目があるチェックリストがあります。それでも実装を進めますか？（yes/no）」
     • 続行する前にユーザーの回答を待ちます
     • ユーザーが「no」「wait」「stop」と回答した場合は、実行を停止します
     • ユーザーが「yes」「proceed」「continue」と回答した場合は、ステップ 3 に進みます

   • すべてのチェックリストにチェックが付いている場合：

     • すべてのチェックリストが合格したことを示す表を表示します
     • 自動的にステップ 3 に進みます

3. 実装コンテキストを読み込み、分析します：

   • 必須：タスクリスト全体と実行計画を把握するため、tasks.md を読みます
   • 必須：技術スタック、アーキテクチャ、ファイル構成を把握するため、plan.md を読みます
   • 存在する場合：エンティティとリレーションシップを把握するため、data-model.md を読みます
   • 存在する場合：API 仕様とテスト要件を把握するため、contracts/ を読みます
   • 存在する場合：技術的な決定事項と制約を把握するため、research.md を読みます
   • 存在する場合：ガバナンス上の制約を把握するため、/memory/constitution.md を読みます
   • 存在する場合：統合シナリオを把握するため、quickstart.md を読みます

4. プロジェクトのセットアップを検証します：

   • 必須：実際のプロジェクト構成に基づいて、除外ファイルを作成または検証します：

   検出と作成のロジック：

   • 次のコマンドが成功するか確認し、リポジトリが Git リポジトリかどうかを判定します（該当する場合は .gitignore を作成または検証します）：

     git rev-parse --git-dir 2>/dev/null
     

   • Dockerfile* が存在するか、plan.md に Docker の記載があるか確認します → .dockerignore を作成または検証します

   • .eslintrc* が存在するか確認します → .eslintignore を作成または検証します

   • eslint.config.* が存在するか確認します → 設定内の ignores エントリに必須パターンが含まれていることを確認します

   • .prettierrc* が存在するか確認します → .prettierignore を作成または検証します

   • .npmrc または package.json が存在するか確認します → （公開する場合）.npmignore を作成または検証します

   • terraform ファイル（*.tf）が存在するか確認します → .terraformignore を作成または検証します

   • .helmignore が必要か確認します（Helm チャートがある場合）→ .helmignore を作成または検証します

   除外ファイルがすでに存在する場合：必須パターンが含まれていることを確認し、不足している重要なパターンのみ追加します 除外ファイルが存在しない場合：検出された技術に応じたパターン一式を含めて作成します

   技術別の一般的なパターン（plan.md の技術スタックに基づく）：

   • Node.js/JavaScript/TypeScript：node_modules/、dist/、build/、*.log、.env*
   • Python：__pycache__/、*.pyc、.venv/、venv/、dist/、*.egg-info/
   • Java：target/、*.class、*.jar、.gradle/、build/
   • C#/.NET：bin/、obj/、*.user、*.suo、packages/
   • Go：*.exe、*.test、vendor/、*.out
   • Ruby：.bundle/、log/、tmp/、*.gem、vendor/bundle/
   • PHP：vendor/、*.log、*.cache、*.env
   • Rust：target/、debug/、release/、*.rs.bk、*.rlib、*.prof*、.idea/、*.log、.env*
   • Kotlin：build/、out/、.gradle/、.idea/、*.class、*.jar、*.iml、*.log、.env*
   • C++：build/、bin/、obj/、out/、*.o、*.so、*.a、*.exe、*.dll、.idea/、*.log、.env*
   • C：build/、bin/、obj/、out/、*.o、*.a、*.so、*.exe、*.dll、autom4te.cache/、config.status、config.log、.idea/、*.log、.env*
   • Swift：.build/、DerivedData/、*.swiftpm/、Packages/
   • R：.Rproj.user/、.Rhistory、.RData、.Ruserdata、*.Rproj、packrat/、renv/
   • 共通：.DS_Store、Thumbs.db、*.tmp、*.swp、.vscode/、.idea/ ツール固有のパターン：
   • Docker：node_modules/、.git/、Dockerfile*、.dockerignore、*.log*、.env*、coverage/
   • ESLint：node_modules/、dist/、build/、coverage/、*.min.js
   • Prettier：node_modules/、dist/、build/、coverage/、package-lock.json、yarn.lock、pnpm-lock.yaml
   • Terraform：.terraform/、*.tfstate*、*.tfvars、.terraform.lock.hcl
   • Kubernetes/k8s：*.secret.yaml、secrets/、.kube/、kubeconfig*、*.key、*.crt

5. tasks.md の構造を解析し、以下を抽出します：

   • タスクフェーズ：セットアップ、テスト、コア、統合、仕上げ
   • タスクの依存関係：順次実行と並列実行のルール
   • タスクの詳細：ID、説明、ファイルパス、並列マーカー [P]
   • 実行フロー：順序と依存関係の要件

6. タスク計画に従って実装を実行します：

   • フェーズごとの実行：次のフェーズに進む前に各フェーズを完了します
   • 依存関係の遵守：順次実行するタスクは順番に実行し、並列タスク [P] は同時に実行できます
   • TDD アプローチの遵守：対応する実装タスクの前にテストタスクを実行します
   • ファイルベースの調整：同じファイルに影響するタスクは順次実行します
   • 検証チェックポイント：次のフェーズに進む前に、各フェーズの完了を確認します

7. 実装の実行ルール：

   • セットアップを最初に実施：プロジェクト構造、依存関係、設定を初期化します
   • コードより先にテスト：コントラクト、エンティティ、統合シナリオのテストを書く必要がある場合は、先にテストを実施します
   • コア開発：モデル、サービス、CLI コマンド、エンドポイントを実装します
   • 統合作業：データベース接続、ミドルウェア、ログ記録、外部サービスを扱います
   • 仕上げと検証：ユニットテスト、パフォーマンス最適化、ドキュメント作成を行います

8. 進捗の追跡とエラー処理：

   • 各タスクの完了後に進捗を報告します
   • 並列ではないタスクが失敗した場合は、実行を停止します
   • 並列タスク [P] の場合は、成功したタスクを続行し、失敗したタスクを報告します
   • デバッグに役立つよう、状況が分かる明確なエラーメッセージを提示します
   • 実装を続行できない場合は、次の手順を提案します
   • 重要 完了したタスクは、tasks ファイルで必ず [X] にします

9. 完了の検証：

   • 必須タスクがすべて完了していることを確認します
   • 実装した機能が元の仕様と一致していることを確認します
   • テストが成功し、カバレッジが要件を満たしていることを検証します
   • 実装が技術計画に沿っていることを確認します

注：このコマンドは、tasks.md にタスクの内訳がすべて記載されていることを前提としています。タスクが不完全、または記載されていない場合は、まず __SPECKIT_COMMAND_TASKS__ を実行してタスクリストを再生成するよう提案してください。

実行後の必須フック

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

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

• 存在しない場合、または hooks.after_implement に登録されたフックがない場合は、「完了報告」に進みます。
• 存在する場合は、それを読み込み、hooks.after_implement キーの下にエントリーがあるか確認します。
• YAML を解析できない場合、または無効な場合は、黙ってスキップせず、.specify/extensions.yml を読み込めなかったこと（パーサーエラーを含む）と、登録されている必須（optional: false）フックを含め、フックを確認していないことをユーザーに伝えてから、「完了報告」に進みます。
• enabled が明示的に false のフックは除外します。enabled フィールドがないフックは、デフォルトで有効として扱います。
• 残りの各フックについて、フックの condition 式を解釈または評価しようとしてはいけません。
  • フックに condition フィールドがない場合、または null／空の場合は、実行可能なフックとして扱います。
  • フックに空でない condition が定義されている場合は、そのフックをスキップし、条件の評価は HookExecutor の実装に委ねます。
• 実行可能な各フックについて、optional フラグに基づいて以下を出力します。
  • 必須フック（optional: false）— 各必須フックについて、必ず EXECUTE_COMMAND: を出力してください。

    ## 拡張フック
    
    **自動フック**：{extension}
    実行中：`/{command}`
    EXECUTE_COMMAND: {command}
    

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

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

完了報告

完了した作業の概要とともに、最終ステータスを報告します。

完了条件

• tasks.md のすべてのタスクが完了し、[X] にマークされている
• 仕様、計画、テストカバレッジに照らして実装が検証されている
• 上記の「実行後の必須フック」のルールに従って、拡張フックが実行またはスキップされている
• 完了した作業の概要とともに、ユーザーに完了が報告されている