speckit-implement

ユーザー入力

$ARGUMENTS

空でない場合は、続行する前にユーザー入力を必ず確認してください。

実行前の確認

実装前に拡張機能フックを確認してください。

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

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

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

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

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

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

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

アウトライン

1. リポジトリのルートから .specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks を実行し、FEATURE_DIR と AVAILABLE_DOCS の一覧を解析します。すべてのパスは絶対パスでなければなりません。「I'm Groot」のように引数にシングルクォートが含まれる場合は、エスケープ構文を使います。例：'I'\''m Groot'（または可能であれば "I'm Groot"）。

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

   • チェックリストのマーカーは読み取り専用のゲートとして扱います。チェックボックスの状態を確認してステータスを報告し、必要な場合は続行する前に確認を求めます。チェックリストファイルやマーカーは変更しないでください。

   • checklists/requirements.md は /speckit-specify と /speckit-clarify が管理する組み込みの仕様品質チェックリストです。/speckit-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：すべてのチェックリストで未チェック項目が 0 件です。
     • FAIL：1 つ以上のチェックリストに未チェック項目があります。

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

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

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

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

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

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

4. プロジェクトのセットアップを確認：

   • 必須：実際のプロジェクト設定に基づいて、ignore ファイルを作成または確認します。

   検出と作成のロジック：

   • 次のコマンドが成功するかどうかを確認して、リポジトリが 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 を作成または確認します

   ignore ファイルがすでに存在する場合：必須パターンが含まれていることを確認し、不足している重要なパターンのみを追加します ignore ファイルが存在しない場合：検出されたテクノロジーに対応するパターン一式を作成します

   テクノロジー別の一般的なパターン（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 の構造を解析し、以下を抽出します：

   • タスクのフェーズ: Setup、Tests、Core、Integration、Polish
   • タスクの依存関係: 順次実行と並列実行のルール
   • タスクの詳細: ID、説明、ファイルパス、並列実行マーカー [P]
   • 実行フロー: 順序と依存関係の要件

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

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

7. 実装の実行ルール：

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

8. 進捗管理とエラー処理：

   • 各タスクの完了後に進捗を報告します
   • 並列実行ではないタスクが失敗した場合は、実行を中止します
   • 並列タスク [P] では、成功したタスクを続行し、失敗したタスクを報告します
   • デバッグに役立つよう、状況を含めた明確なエラーメッセージを提示します
   • 実装を進められない場合は、次のステップを提案します
   • 重要 完了したタスクは、必ずタスクファイルで [X] にマークしてください。

9. 完了の検証：

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

注：このコマンドは、tasks.md に完全なタスク分解が存在することを前提としています。タスクが不完全または存在しない場合は、タスクリストを再生成するために、まず /speckit-tasks を実行するよう提案してください。

実行後に必須のフック

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

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

• 存在しない場合、または hooks.after_implement に登録されているフックがない場合は、「完了レポート」へ進んでください。
• 存在する場合は読み込み、hooks.after_implement キーの下にエントリーがあるか確認してください。
• 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}
    実行中：`/{command}`
    EXECUTE_COMMAND: {command}
    

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

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

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

完了レポート

完了した作業の概要を添えて、最終ステータスを報告してください。

完了条件

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