speckit.implement

Prompt file imported from Chabana1591/my-project (.codex/prompts/speckit.implement.md). Fill in {{arguments}} before use. Copyright stays with the author.

ユーザー入力

{{arguments}}

続行する前に、ユーザー入力を必ず考慮してください（空でない場合）。

概要

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/ ディレクトリ内のすべてのチェックリストファイルをスキャン

   • 各チェックリストについて、以下をカウント:

     • 合計項目: - [ ] または - [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 を読み込む
   • 存在する場合: 統合シナリオのため 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、Makefile、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 構造を解析して抽出:

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

6. タスク計画に従って実装を実行:

   • フェーズごとの実行: 次に進む前に各フェーズを完了
   • 依存関係を尊重: 順次タスクは順番に実行、並列タスク [P] は一緒に実行可能
   • TDD アプローチに従う: 対応する実装タスクの前にテストタスクを実行
   • ファイルベースの調整: 同じファイルに影響するタスクは順次実行必須
   • 検証チェックポイント: 進む前に各フェーズの完了を検証

7. 実装実行ルール:

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

8. 進捗追跡とエラーハンドリング:

   • 各完了タスク後に進捗を報告
   • 非並列タスクが失敗した場合は実行を停止
   • 並列タスク [P] の場合、成功したタスクを続行し、失敗したものを報告
   • デバッグのためのコンテキスト付きの明確なエラーメッセージを提供
   • 実装を続行できない場合は次のステップを提案
   • 重要 完了したタスクについては、タスクファイルでタスクを [X] としてマークすることを確認

9. 完了検証:

   • すべての必須タスクが完了していることを検証
   • 実装された機能が元の仕様と一致することを確認
   • テストが合格し、カバレッジが要件を満たしていることを検証
   • 実装が技術計画に従っていることを確認
   • 完了した作業のサマリーを含む最終ステータスを報告

注意: このコマンドは tasks.md に完全なタスク分解が存在することを前提としています。タスクが不完全または欠落している場合は、タスクリストを再生成するために最初に /speckit.tasks を実行することを提案します。