diff --git a/MANUAL.md b/MANUAL.md index d009b8c..666cbd7 100644 --- a/MANUAL.md +++ b/MANUAL.md @@ -15,6 +15,25 @@ mkdir -p .claude cp -r commands .claude/ ``` +#### オプション：プロジェクト固有のルール設定 + +セットアップ後、プロジェクト固有のルールや設定を追加できます。 +`docs/rule/{種類1}/{種類2}` ディレクトリ構造でファイルを配置すると、対応するコマンド実行時に自動で読み込まれます。 + +**読み込まれるディレクトリ階層**: +- `docs/rule/` （共通ルール） +- `docs/rule/{種類1}/` （種類レベルのルール） +- `docs/rule/{種類1}/{種類2}/` （詳細レベルのルール） + +**例**: `kairo-requirements` 実行時 +``` +docs/rule/ # 全コマンド共通ルール +docs/rule/kairo/ # kairoコマンド共通ルール +docs/rule/kairo/requirements/ # kairo-requirements専用ルール +``` + +これらのディレクトリ内の `.md` ファイルは、コマンド実行時にコンテキストとして自動読み込みされます。 + ### TDDコマンド TASK作成時に `TDD` と判定している場合で個別にTDDプロセスを実行したい場合は、以下のコマンドを順次実行できます： @@ -56,7 +75,19 @@ TASK作成時に `DIRECT` と判定している場合は、以下のコマンド ### Kairoコマンド（包括的フロー） -#### 1. 要件定義 +#### 1. 技術スタック初期化 + +プロジェクトの技術スタック（フレームワーク、ライブラリ）を初期化します： + +``` +/init-tech-stack + +``` +init-tech-stack は以下を生成します： + +生成されたファイル: `/docs/tech-stack.md` 配下 + +#### 2. 要件定義 最初に、プロジェクトの要件概要をKairoに伝えます： @@ -77,7 +108,7 @@ Kairoは以下を生成します： 生成されたファイル: `/docs/spec/{要件名}-requirements.md` -#### 2. 設計 +#### 3. 設計 要件を確認・修正した後、設計を依頼します： @@ -96,7 +127,7 @@ Kairoは以下を生成します： 生成されたファイル: `/docs/design/{要件名}/` 配下 -#### 3. タスク分割 +#### 4. タスク分割 設計を確認した後（承認は省略可）、タスク分割を実行します： @@ -115,7 +146,7 @@ Kairoは以下を生成します： 生成されたファイル: `/docs/tasks/{要件名}-tasks.md` -#### 4. 実装 +#### 5. 実装 タスクを確認した後、実装を開始します： （TDDサイクルまたはDIRECTを手動実行をお勧めします diff --git a/README.md b/README.md index b02dd2a..ed45758 100644 --- a/README.md +++ b/README.md @@ -30,6 +30,8 @@ Kairoは要件定義から実装までの開発プロセスを自動化・支援 ## 利用可能なコマンド +- `init-tech-stack` - 技術スタックの特定 + ### Kairoコマンド（包括的開発フロー） - `kairo-requirements` - 要件定義 - `kairo-design` - 設計文書生成 @@ -55,16 +57,19 @@ Kairoは要件定義から実装までの開発プロセスを自動化・支援 ### 包括的な開発フロー ```bash -# 1. 要件定義 +# 1. 技術スタック初期化 +/init-tech-stack + +# 2. 要件定義 /kairo-requirements -# 2. 設計 +# 3. 設計 /kairo-design -# 3. タスク分割 +# 4. タスク分割 /kairo-tasks -# 4. 実装 +# 5. 実装 /kairo-implement ``` diff --git a/commands/direct-setup.md b/commands/direct-setup.md index 7d0011a..67b6da8 100644 --- a/commands/direct-setup.md +++ b/commands/direct-setup.md @@ -16,13 +16,25 @@ DIRECTタスクの設定作業を実行します。設計文書に基づいて ## 実行内容 -1. **設計文書の確認** +1. **追加ルールの読み込み** + - `docs/rule` ディレクトリが存在する場合は読み込み + - `docs/rule/direct` ディレクトリが存在する場合は読み込み + - `docs/rule/direct/setup` ディレクトリが存在する場合は読み込み + - 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用 + +2. **技術スタック定義の読み込み** + - `docs/tech-stack.md` が存在する場合は読み込み + - 存在しない場合は `CLAUDE.md` から技術スタックセクションを読み込み + - どちらも存在しない場合は `.claude/commands/tech-stack.md` のデフォルト定義を使用 + +3. **設計文書の確認** + - 読み込んだ技術スタック定義に基づいて関連ファイルを特定 - @agent-symbol-searcher で関連設計文書や設定パターンを検索し、見つかったファイルをReadツールで読み込み - `docs/design/{要件名}/architecture.md` をReadツールで読み込み - `docs/design/{要件名}/database-schema.sql` をReadツールで読み込み - その他関連する設計文書をReadツールで読み込み -2. **設定作業の実行** +3. **設定作業の実行** - @agent-symbol-searcher で既存の設定ファイルや環境変数を検索し、見つかったファイルをReadツールで読み込み - 環境変数の設定 - 設定ファイルの作成・更新 @@ -31,14 +43,14 @@ DIRECTタスクの設定作業を実行します。設計文書に基づいて - サービスの起動設定 - 権限の設定 -3. **作業記録の作成** +4. **作業記録の作成** - 実行したコマンドの記録 - 変更した設定の記録 - 遭遇した問題と解決方法の記録 ## 出力先 -作業記録は `docs/implements/{TASK-ID}/` ディレクトリに以下のファイルとして作成されます： +作業記録は `docs/implements/{要件名}/{TASK-ID}/` ディレクトリに以下のファイルとして作成されます： - `setup-report.md`: 設定作業実行記録 ## 出力フォーマット例 @@ -137,7 +149,7 @@ psql -d mydb -f database-schema.sql ``` ## 実行後の確認 -- `docs/implements/{TASK-ID}/setup-report.md` ファイルが作成されていることを確認 +- `docs/implements/{要件名}/{TASK-ID}/setup-report.md` ファイルが作成されていることを確認 - 設定が正しく適用されていることを確認 - 次のステップ（direct-verify）の準備が整っていることを確認 @@ -145,6 +157,6 @@ psql -d mydb -f database-schema.sql 実行前に必要なディレクトリを作成してください： ```bash -mkdir -p docs/implements/{TASK-ID} +mkdir -p docs/implements/{要件名}/{TASK-ID} ``` ``` diff --git a/commands/direct-verify.md b/commands/direct-verify.md index 4195a65..b47f55f 100644 --- a/commands/direct-verify.md +++ b/commands/direct-verify.md @@ -18,35 +18,47 @@ DIRECTタスクで実行した設定作業の動作確認とテストを行い **【重要】**: direct-setupで作成されたファイルについて、コンパイルエラーや構文エラーが見つかった場合は自動的に解決を試行します。 -1. **設定の確認** +1. **追加ルールの読み込み** + - `docs/rule` ディレクトリが存在する場合は読み込み + - `docs/rule/direct` ディレクトリが存在する場合は読み込み + - `docs/rule/direct/verify` ディレクトリが存在する場合は読み込み + - 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用 + +2. **技術スタック定義の読み込み** + - `docs/tech-stack.md` が存在する場合は読み込み + - 存在しない場合は `CLAUDE.md` から技術スタックセクションを読み込み + - どちらも存在しない場合は `.claude/commands/tech-stack.md` のデフォルト定義を使用 + +3. **設定の確認** + - 読み込んだ技術スタック定義に基づいて検証項目を特定 - @agent-symbol-searcher で関連設定や検証パターンを検索し、見つかったファイルをReadツールで読み込み - - `docs/implements/{TASK-ID}/setup-report.md` をReadツールで読み込み、設定作業の結果を確認 + - `docs/implements/{要件名}/{TASK-ID}/setup-report.md` をReadツールで読み込み、設定作業の結果を確認 - 環境変数の確認 - 設定ファイルの内容確認 - 依存関係のインストール状況確認 - サービスの起動状況確認 -2. **コンパイル・構文確認** +3. **コンパイル・構文確認** - TypeScript/JavaScript構文エラーチェック（該当する場合） - 設定ファイルの構文確認（JSON, YAML等） - SQL構文確認（該当する場合） - 最低限のコンパイルエラー解消 -3. **動作テストの実行** +4. **動作テストの実行** - @agent-symbol-searcher で既存のテストケースや検証スクリプトを検索し、見つかったファイルをReadツールで読み込み - 基本的な動作確認 - 接続テスト - 権限の確認 - エラーケースの確認 -4. **品質チェック** +5. **品質チェック** - セキュリティ設定の確認 - パフォーマンス基準の確認 - ログの確認 ## 出力先 -確認記録は `docs/implements/{TASK-ID}/` ディレクトリに以下のファイルとして作成されます： +確認記録は `docs/implements/{要件名}/{TASK-ID}/` ディレクトリに以下のファイルとして作成されます： - `verify-report.md`: 設定確認・動作テスト記録 ## 出力フォーマット例 @@ -288,7 +300,7 @@ jq '.port = 3000' config.json > temp.json && mv temp.json config.json ```` ## 実行後の確認 -- `docs/implements/{TASK-ID}/verify-report.md` ファイルが作成されていることを確認 +- `docs/implements/{要件名}/{TASK-ID}/verify-report.md` ファイルが作成されていることを確認 - 全ての確認項目が完了していることを確認 - 問題が発見された場合は適切に対処されていることを確認 - タスクの完了条件を満たしていることを確認 @@ -296,10 +308,10 @@ jq '.port = 3000' config.json > temp.json && mv temp.json config.json ## ディレクトリ確認 -`docs/implements/{TASK-ID}/` ディレクトリが存在することを確認してください（direct-setupで作成済みのはず） +`docs/implements/{要件名}/{TASK-ID}/` ディレクトリが存在することを確認してください（direct-setupで作成済みのはず） ## タスクの完了マーキング -品質チェックが十分で、全ての確認項目がクリアされた場合は、tasksディレクトリの該当するタスクファイルに完了マークを付けてください。 +品質チェックが十分で、全ての確認項目がクリアされた場合は、**自動的に**tasksディレクトリの該当するタスクファイルに完了マークを付けてください。 ### 完了条件 以下の条件を全て満たす場合にタスクを完了とマークします： @@ -312,9 +324,12 @@ jq '.port = 3000' config.json > temp.json && mv temp.json config.json - [ ] パフォーマンス基準を満たしている ### 完了マークの付け方 -1. ユーザが指定したタスクファイルを確認 -2. ファイル内の該当セクションまたはタスク項目に `✅ 完了` または `[COMPLETED]` マークを追加 -3. 完了日時と確認者を記録 +1. `docs/implements/{要件名}/{TASK-ID}/verify-report.md` で完了条件を確認 +2. 該当するタスクファイル（taskman-phase*.md）を特定 +3. タスクの完了状況を以下のように更新： + - `- [ ] **タスク完了**` → `- [x] **タスク完了** ✅ 完了 (YYYY-MM-DD)` + - 完了条件のチェックボックスも `[x]` に変更 +4. 必要に応じて進捗概要（taskman-overview.md）も更新 ## README.mdの更新 タスクが完了した場合、プロジェクトのルートディレクトリの `README.md` を作成または更新してください。 diff --git a/commands/init-tech-stack.md b/commands/init-tech-stack.md new file mode 100644 index 0000000..e810a0e --- /dev/null +++ b/commands/init-tech-stack.md @@ -0,0 +1,573 @@ +--- +description: プロジェクトの初期設定として技術スタックの選定をします。既にCLAUDE.mdがある場合は省略できます +--- + +# init-tech-stack + +## 目的 + +ユーザとのインタラクティブなやりとりを通じて、プロジェクトに最適な技術スタック定義を作成し、`docs/tech-stack.md` ファイルを生成します。 + +## 前提条件 + +- プロジェクトルートディレクトリで実行 +- `docs/` ディレクトリが存在する（なければ作成） + +## 実行内容 + +段階的なヒアリングを通じて技術選択を行い、最終的に `docs/tech-stack.md` を生成します。 + +## ヒアリングフロー + +### Phase 1: プロジェクト基本情報 + +まず、プロジェクトの基本情報をお聞かせください。 + +#### 質問1: プロジェクトタイプ +以下から最も近いものを選択してください： + +1. **Webアプリケーション** - ブラウザで動作するアプリケーション +2. **モバイルアプリ** - スマートフォン/タブレット向けアプリ +3. **API/バックエンドサービス** - API提供がメインのサービス +4. **デスクトップアプリケーション** - PC向けネイティブアプリ +5. **ライブラリ/SDK** - 他の開発者向けのツール +6. **フルスタック（Web + API）** - フロントエンドとバックエンドの両方 +7. **その他** - 上記以外 + +**あなたの選択**: [ユーザー入力を待つ] + +--- + +#### 質問2: プロジェクト規模 +開発チームの規模を教えてください： + +1. **個人開発** - 1人で開発 +2. **小規模チーム** - 2-5人 +3. **中規模チーム** - 6-15人 +4. **大規模チーム** - 16人以上 + +**あなたの選択**: [ユーザー入力を待つ] + +--- + +#### 質問3: 開発期間 +予定している開発期間はどの程度ですか？ + +1. **プロトタイプ/MVP** - 1-2ヶ月 +2. **短期プロジェクト** - 3-6ヶ月 +3. **中期プロジェクト** - 6ヶ月-1年 +4. **長期プロジェクト** - 1年以上 + +**あなたの選択**: [ユーザー入力を待つ] + +--- + +### Phase 2: 技術制約・要件 + +#### 質問4: 既存システム連携 +既存のシステムやデータベースとの連携はありますか？ + +1. **新規構築** - 全て新しく作成 +2. **既存DB連携あり** - 既存データベースを使用 +3. **既存API連携あり** - 既存のAPIと連携 +4. **レガシーシステム移行** - 既存システムからの移行 +5. **その他連携要件あり** - 具体的に教えてください + +**あなたの選択**: [ユーザー入力を待つ] + +**既存技術がある場合は具体的に**: [ユーザー入力を待つ] + +--- + +#### 質問5: パフォーマンス要件 +想定される負荷や性能要件を教えてください： + +1. **軽負荷** - 同時利用者数10人以下、レスポンス時間3秒以内 +2. **中負荷** - 同時利用者数100人程度、レスポンス時間1秒以内 +3. **高負荷** - 同時利用者数1000人以上、レスポンス時間0.5秒以内 +4. **未定/不明** - まだ詳細は決まっていない + +**あなたの選択**: [ユーザー入力を待つ] + +--- + +#### 質問6: セキュリティ要件 +セキュリティの重要度を教えてください： + +1. **基本的なセキュリティ** - 一般的なWebセキュリティ対策 +2. **高度なセキュリティ** - 個人情報取り扱い、金融系など +3. **エンタープライズレベル** - 企業向け、コンプライアンス要件あり +4. **未定/不明** - まだ詳細は決まっていない + +**あなたの選択**: [ユーザー入力を待つ] + +--- + +### Phase 3: チーム・スキル状況 + +#### 質問7: チームの技術スキル +チームメンバーの技術経験を教えてください（複数選択可）： + +1. **JavaScript/TypeScript** - 経験豊富 +2. **Python** - 経験豊富 +3. **Java/Kotlin** - 経験豊富 +4. **C#/.NET** - 経験豊富 +5. **PHP** - 経験豊富 +6. **Go/Rust** - 経験豊富 +7. **React/Vue/Angular** - 経験豊富 +8. **データベース設計** - 経験豊富 +9. **クラウド（AWS/Azure/GCP）** - 経験豊富 +10. **Docker/Kubernetes** - 経験豊富 +11. **技術スキルは限定的** - 学習しながら進めたい + +**あなたの選択（複数可）**: [ユーザー入力を待つ] + +--- + +#### 質問8: 学習コスト許容度 +新しい技術の習得についてどう考えますか？ + +1. **積極的に新技術を導入したい** - 最新技術でチャレンジしたい +2. **バランス重視** - 新技術と安定技術のバランスを取りたい +3. **安定技術優先** - 枯れた技術で確実に開発したい +4. **既存スキル活用** - チームが知っている技術を最大限活用したい + +**あなたの選択**: [ユーザー入力を待つ] + +--- + +### Phase 4: 運用・インフラ要件 + +#### 質問9: デプロイ・ホスティング +アプリケーションをどこで動かす予定ですか？ + +1. **クラウド（AWS/Azure/GCP）** - パブリッククラウド +2. **PaaS（Vercel/Netlify/Heroku）** - 簡単デプロイ重視 +3. **VPS/専用サーバー** - 自前サーバー +4. **オンプレミス** - 社内サーバー +5. **未定** - まだ決まっていない + +**あなたの選択**: [ユーザー入力を待つ] + +--- + +#### 質問10: 予算制約 +開発・運用コストについて教えてください： + +1. **コスト最小化** - 無料・低コストツール優先 +2. **バランス重視** - 適度なコストは許容 +3. **品質重視** - コストより品質・効率を優先 +4. **予算潤沢** - 最適なツールを選択可能 + +**あなたの選択**: [ユーザー入力を待つ] + +--- + +## 技術スタック推奨ロジック + +### 推奨アルゴリズム + +ユーザーの回答に基づいて以下のロジックで技術を推奨： + +#### フロントエンド選択 +``` +IF プロジェクトタイプ == "Webアプリケーション" OR "フルスタック" + IF チーム経験に "React/Vue/Angular" あり + IF 学習コスト許容度 == "積極的" + 推奨: React 18 + TypeScript (最新技術) + ELSE + 推奨: React 18 + JavaScript (安定性重視) + ELSE IF JavaScript経験あり + 推奨: Vue 3 + TypeScript (学習コスト低) + ELSE + 推奨: Next.js (フルスタック簡単) +``` + +#### バックエンド選択 +``` +IF JavaScript経験豊富 + 推奨: Node.js + Express/Fastify +ELSE IF Python経験豊富 + 推奨: FastAPI/Django +ELSE IF 他言語経験豊富 + その言語のフレームワーク推奨 +ELSE + 推奨: Node.js (フロントエンドとの統一) +``` + +#### データベース選択 +``` +IF パフォーマンス要件 == "高負荷" + 推奨: PostgreSQL + Redis +ELSE IF セキュリティ要件 == "高度" + 推奨: PostgreSQL +ELSE IF プロジェクト規模 == "個人" OR "小規模" + 推奨: SQLite → PostgreSQL (段階移行) +ELSE + 推奨: PostgreSQL +``` + +### 推奨結果表示 + +各フェーズの回答後、ライブラリの最新バージョンやLTS版を検索して、以下の形式で推奨結果を表示： + +```markdown +# あなたの回答に基づく技術スタック推奨 + +## 📋 回答サマリー +- プロジェクトタイプ: Webアプリケーション +- 規模: 小規模チーム（3人） +- 期間: 中期プロジェクト（8ヶ月） +- 技術スキル: JavaScript/TypeScript経験豊富 +- 学習コスト許容度: バランス重視 + +## 🚀 推奨技術スタック + +### フロントエンド +✅ **React 18 + TypeScript** + - 理由: チームのReact経験を活かせます + - メリット: 豊富なエコシステム、求人市場での優位性 + - 学習コスト: 中（既存経験あり） + +⚠️ **Vue 3 + TypeScript** （代替案） + - 理由: より学習コストが低い + - メリット: シンプルな構文、段階的導入可能 + - 学習コスト: 低 + +❌ **Angular** （非推奨） + - 理由: 中期プロジェクトには重すぎる + - デメリット: 学習コスト高、小規模チームに不向き + +### バックエンド +✅ **Node.js + Express + TypeScript** + - 理由: フロントエンドとの言語統一 + - メリット: 開発効率、人材リソースの有効活用 + - 学習コスト: 低（既存JavaScript経験） + +### データベース +✅ **PostgreSQL** + - 理由: 中期プロジェクトの成長に対応 + - メリット: ACID準拠、拡張性、JSON対応 + - 学習コスト: 中 + +✅ **Redis** （キャッシュ） + - 理由: パフォーマンス向上 + - メリット: セッション管理、高速キャッシュ + - 学習コスト: 低 + +### 開発環境 +✅ **Docker + Docker Compose** + - 理由: 環境統一、デプロイ簡素化 + - メリット: 開発環境の一貫性 + - 学習コスト: 中 + +✅ **Jest + Testing Library** + - 理由: React標準、TypeScript親和性 + - メリット: 豊富なドキュメント + - 学習コスト: 低 + +## ⚙️ 整合性チェック + +✅ **技術選択の整合性**: 問題なし +- React + Node.js: 言語統一によるシナジー効果 +- TypeScript: フロント・バック全体での型安全性 +- PostgreSQL: 将来の成長に対応可能 + +✅ **チームスキルとのマッチング**: 良好 +- 既存JavaScript/TypeScript経験を最大活用 +- 学習が必要な新技術は最小限 + +✅ **プロジェクト要件との適合性**: 適合 +- 中期プロジェクト向けの拡張性 +- 小規模チームでの管理容易性 + +この推奨で進めますか？ + +1. **はい** - この推奨で `docs/tech-stack.md` を生成 +2. **一部変更したい** - 個別技術を調整 +3. **全体的に見直したい** - ヒアリングからやり直し + +**あなたの選択**: [ユーザー入力を待つ] +``` + +## カスタマイズ対応 + +「一部変更したい」を選択された場合： + +```markdown +# 技術スタックのカスタマイズ + +どの部分を変更しますか？ + +1. **フロントエンド** (現在: React 18 + TypeScript) +2. **バックエンド** (現在: Node.js + Express + TypeScript) +3. **データベース** (現在: PostgreSQL + Redis) +4. **開発環境・ツール** (現在: Docker, Jest等) +5. **全て確認して個別調整** + +**選択**: [ユーザー入力を待つ] + +--- + +## フロントエンドの変更 + +現在の推奨: **React 18 + TypeScript** + +利用可能な選択肢： + +1. **React 18 + TypeScript** ⭐ (現在の推奨) +2. **React 18 + JavaScript** - TypeScriptを使わない場合 +3. **Vue 3 + TypeScript** - より軽量なフレームワーク +4. **Vue 3 + JavaScript** - 最も学習コストが低い +5. **Next.js + TypeScript** - フルスタックフレームワーク +6. **Svelte/SvelteKit** - 新しいアプローチ +7. **Angular + TypeScript** - エンタープライズ向け +8. **Vanilla JavaScript + TypeScript** - フレームワークなし +9. **その他** - 具体的に指定 + +**あなたの選択**: [ユーザー入力を待つ] + +**選択理由があれば**: [ユーザー入力を待つ] +``` + +## 最終生成処理 + +最終確認後、以下の処理を実行： + +1. **ディレクトリ作成** +```bash +mkdir -p docs +``` + +2. **`docs/tech-stack.md` 生成** + +生成されるファイル例： + +```markdown +# プロジェクト技術スタック定義 + +## 🔧 生成情報 +- **生成日**: 2025-01-08 +- **生成ツール**: init-tech-stack.md +- **プロジェクトタイプ**: Webアプリケーション +- **チーム規模**: 小規模チーム（3人） +- **開発期間**: 中期プロジェクト（8ヶ月） + +## 🎯 プロジェクト要件サマリー +- **パフォーマンス**: 中負荷（同時利用者数100人程度） +- **セキュリティ**: 基本的なWebセキュリティ対策 +- **技術スキル**: JavaScript/TypeScript経験豊富 +- **学習コスト許容度**: バランス重視 +- **デプロイ先**: クラウド（AWS/Azure/GCP） +- **予算**: バランス重視 + +## 🚀 フロントエンド +- **フレームワーク**: React 18.2 +- **言語**: TypeScript 5.0+ +- **状態管理**: Redux Toolkit +- **UIライブラリ**: Material-UI v5 +- **バンドラー**: Vite +- **ルーティング**: React Router v6 + +### 選択理由 +- チームのReact経験を活かせる +- TypeScriptで型安全性を確保 +- Material-UIで開発速度向上 +- Viteで高速な開発環境 + +## ⚙️ バックエンド +- **フレームワーク**: Express.js 4.18 +- **言語**: TypeScript 5.0+ +- **データベース**: PostgreSQL 15 +- **ORM**: Prisma +- **認証**: JWT + Refresh Token +- **キャッシュ**: Redis 7+ + +### 選択理由 +- フロントエンドとの言語統一 +- Prismaで型安全なDB操作 +- PostgreSQLで将来のスケーリングに対応 +- Redisでセッション管理とキャッシュ + +## 💾 データベース設計 +- **メインDB**: PostgreSQL 15+ +- **キャッシュ**: Redis 7+ +- **ファイルストレージ**: AWS S3 / Azure Blob (本番), ローカル (開発) + +### 設計方針 +- ACID準拠のトランザクション +- JSON型でNoSQL的な柔軟性も確保 +- インデックス戦略でクエリ最適化 +- 適切な正規化レベル + +## 🛠️ 開発環境 +- **コンテナ**: Docker + Docker Compose +- **パッケージマネージャー**: npm +- **Node.js**: 18+ LTS + +### 開発ツール +- **テストフレームワーク**: Jest +- **テストライブラリ**: React Testing Library +- **E2Eテスト**: Playwright +- **リンター**: ESLint + Prettier +- **型チェック**: TypeScript + +### CI/CD +- **CI/CD**: GitHub Actions +- **コード品質**: ESLint, Prettier, TypeScript +- **テスト**: Unit, Integration, E2E +- **デプロイ**: 自動デプロイ with approval + +## ☁️ インフラ・デプロイ +- **フロントエンド**: Vercel / Netlify +- **バックエンド**: AWS ECS / Azure Container Apps +- **データベース**: AWS RDS / Azure Database +- **キャッシュ**: AWS ElastiCache / Azure Cache +- **CDN**: CloudFlare / AWS CloudFront + +## 🔒 セキュリティ +- **HTTPS**: 必須 (証明書自動更新) +- **認証**: JWT + Refresh Token +- **CORS**: 適切な設定 +- **バリデーション**: サーバーサイドバリデーション +- **環境変数**: 機密情報の適切な管理 +- **依存関係**: 定期的な脆弱性チェック + +## 📊 品質基準 +- **テストカバレッジ**: 80%以上 +- **コード品質**: ESLint + Prettier +- **型安全性**: TypeScript strict mode +- **パフォーマンス**: Lighthouse 90+点 +- **アクセシビリティ**: WCAG 2.1 AA準拠 + +## 📁 推奨ディレクトリ構造 + +``` +project-root/ +├── frontend/ # React アプリケーション +│ ├── src/ +│ │ ├── components/ # 再利用可能コンポーネント +│ │ ├── pages/ # ページコンポーネント +│ │ ├── hooks/ # カスタムフック +│ │ ├── store/ # Redux store +│ │ ├── types/ # 型定義 +│ │ └── utils/ # ユーティリティ +│ ├── public/ # 静的ファイル +│ ├── package.json +│ └── vite.config.ts +├── backend/ # Express API +│ ├── src/ +│ │ ├── controllers/ # API コントローラー +│ │ ├── services/ # ビジネスロジック +│ │ ├── models/ # データモデル +│ │ ├── middleware/ # Express ミドルウェア +│ │ ├── routes/ # API ルート定義 +│ │ ├── types/ # 型定義 +│ │ └── utils/ # ユーティリティ +│ ├── prisma/ # データベーススキーマ +│ ├── tests/ # テストファイル +│ ├── package.json +│ └── tsconfig.json +├── docs/ # プロジェクトドキュメント +├── docker-compose.yml # 開発環境 +└── README.md # プロジェクト概要 +``` + +## 🚀 セットアップ手順 + +### 1. 開発環境準備 +```bash +# Docker環境起動 +docker-compose up -d + +# フロントエンド セットアップ +cd frontend +npm install +npm run dev + +# バックエンド セットアップ +cd backend +npm install +npx prisma migrate dev +npm run dev +``` + +### 2. 主要コマンド +```bash +# 開発サーバー起動 +npm run dev # フロントエンド +npm run dev:api # バックエンド + +# テスト実行 +npm test # 単体テスト +npm run test:e2e # E2Eテスト + +# ビルド +npm run build # 本番ビルド +npm run preview # ビルド確認 + +# データベース +npx prisma studio # DB管理画面 +npx prisma generate # クライアント生成 +``` + +## 📝 カスタマイズ方法 + +このファイルはプロジェクトの進行に応じて更新してください： + +1. **技術の追加**: 新しいライブラリ・ツールを追加 +2. **要件の変更**: パフォーマンス・セキュリティ要件の更新 +3. **インフラの変更**: デプロイ先・スケール要件の変更 +4. **チーム変更**: メンバー増減に応じた技術選択の見直し + +## 🔄 更新履歴 +- 2025-01-08: 初回生成 (init-tech-stack.mdにより自動生成) +``` + +3. **確認メッセージ表示** + +```markdown +✅ 技術スタック定義ファイルを生成しました！ + +📄 **生成ファイル**: `docs/tech-stack.md` +📊 **技術数**: フロントエンド6技術、バックエンド6技術、開発環境8ツール +🎯 **推奨理由**: チーム経験との適合性、プロジェクト要件への最適化 + +## 次のステップ + +1. **ファイル確認**: `docs/tech-stack.md` の内容を確認 +2. **カスタマイズ**: 必要に応じて技術選択を微調整 +3. **チーム共有**: 技術選択をチームで合意 +4. **開発開始**: 他のkairo-*コマンドで要件定義・設計に進む + +## 技術スタック更新 + +技術選択を変更する場合は： +- `docs/tech-stack.md` を直接編集 +- または `init-tech-stack.md` を再実行 + +このファイルは他の全てのコマンド（kairo-*, tdd-*, direct-*）で自動参照されます。 +``` + +## エラーハンドリング + +```markdown +## よくある問題と解決方法 + +### ❌ ファイル作成エラー +**原因**: `docs/` ディレクトリへの書き込み権限なし +**解決**: `mkdir -p docs && chmod 755 docs` + +### ❌ 既存ファイル上書き警告 +**原因**: `docs/tech-stack.md` が既に存在 +**選択肢**: +1. 上書きする +2. バックアップを作成してから上書き +3. 別名で保存（例：`tech-stack-new.md`） + +### ❌ 推奨技術が見つからない +**原因**: 特殊な技術要件や制約 +**対処**: カスタマイズモードで手動選択 +``` + +このように、段階的なヒアリングとインテリジェントな推奨機能により、プロジェクトに最適な技術スタック定義が自動生成される仕組みを作成しました。 \ No newline at end of file diff --git a/commands/kairo-design.md b/commands/kairo-design.md index db2a148..119868d 100644 --- a/commands/kairo-design.md +++ b/commands/kairo-design.md @@ -13,49 +13,66 @@ description: 承認された要件定義書に基づいて、技術設計文書 - `docs/spec/` に要件定義書が存在する - 要件がユーザによって承認されている +## 事前準備 + +1. **追加ルールの読み込み** + - `docs/rule` ディレクトリが存在する場合は読み込み + - `docs/rule/kairo` ディレクトリが存在する場合は読み込み + - `docs/rule/kairo/design` ディレクトリが存在する場合は読み込み + - 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用 + ## 実行内容 **【信頼性レベル指示】**: 各項目について、元の資料（EARS要件定義書・設計文書含む）との照合状況を以下の信号でコメントしてください： -- 🟢 **青信号**: EARS要件定義書・設計文書を参考にしてほぼ推測していない場合 +- 🔵 **青信号**: EARS要件定義書・設計文書を参考にしてほぼ推測していない場合 - 🟡 **黄信号**: EARS要件定義書・設計文書から妥当な推測の場合 - 🔴 **赤信号**: EARS要件定義書・設計文書にない推測の場合 -1. **要件の分析** +2. **技術スタック定義の読み込み** + - `docs/tech-stack.md` が存在する場合は読み込み + - 存在しない場合は `CLAUDE.md` から技術スタックセクションを読み込み + - どちらも存在しない場合は `.claude/commands/tech-stack.md` のデフォルト定義を使用 + +3. **要件の分析** - @agent-symbol-searcher で要件定義書を検索し、見つかったファイルをReadツールで読み込み - @agent-symbol-searcher で関連する既存設計文書を確認し、見つかったファイルをReadツールで読み込み + - 読み込んだ技術スタック定義に基づいて技術選択を決定 - 機能要件と非機能要件を整理する - システムの境界を明確にする -2. **アーキテクチャ設計** +4. **アーキテクチャ設計** - システム全体のアーキテクチャを決定 - フロントエンド/バックエンドの分離 - マイクロサービスの必要性を検討 -3. **データフロー図の作成** +5. **データフロー図の作成** - Mermaid記法でデータフローを可視化 - ユーザーインタラクションの流れ - システム間のデータの流れ -4. **TypeScriptインターフェースの定義** +6. **TypeScriptインターフェースの定義** + - NEVER 対象言語がTypeScriptで無い場合はそれに合わせたファイル形式に変更する。インタフェース定義が不要なら生成しない - エンティティの型定義 - APIリクエスト/レスポンスの型定義 - 共通型の定義 -5. **データベーススキーマの設計** +8. **データベーススキーマの設計** + - NEVER 対象がデータベーススキーマが不要の場合は生成しない - テーブル定義 - リレーションシップ - インデックス戦略 - 正規化レベルの決定 -6. **APIエンドポイントの設計** +9. **APIエンドポイントの設計** + - NEVER 対象にAPIではない場合、または既存のAPIを利用する場合は生成しない - RESTful API設計 - エンドポイントの命名規則 - HTTPメソッドの適切な使用 - リクエスト/レスポンスの構造 -7. **ファイルの作成** +10. **ファイルの作成** - `docs/design/{要件名}/` ディレクトリに以下を作成： - `architecture.md` - アーキテクチャ概要 - `dataflow.md` - データフロー図 diff --git a/commands/kairo-implement.md b/commands/kairo-implement.md index 80316b5..a3b60df 100644 --- a/commands/kairo-implement.md +++ b/commands/kairo-implement.md @@ -1,6 +1,7 @@ --- description: 分割されたタスクを順番に、またはユーザが指定したタスクを実装します。既存のTDDコマンドを活用して品質の高い実装を行います。 --- +あなたは実装担当者です。残タスクを調べて 指定されたコマンドを駆使して実装をしてください # kairo-implement @@ -14,36 +15,49 @@ description: 分割されたタスクを順番に、またはユーザが指定 - ユーザがタスクの実装を承認している - 既存のTDDコマンドが利用可能である - 実装用のワークスペースが設定されている +- task_id は　`TASK-{4桁の数字}` (例 TASK-0001 ) である ## 実行内容 **【信頼性レベル指示】**: 各項目について、元の資料（EARS要件定義書・設計文書含む）との照合状況を以下の信号でコメントしてください： -- 🟢 **青信号**: EARS要件定義書・設計文書を参考にしてほぼ推測していない場合 +- 🔵 **青信号**: EARS要件定義書・設計文書を参考にしてほぼ推測していない場合 - 🟡 **黄信号**: EARS要件定義書・設計文書から妥当な推測の場合 - 🔴 **赤信号**: EARS要件定義書・設計文書にない推測の場合 -1. **タスクの選択** - - @agent-symbol-searcher で指定されたタスクIDを検索し、見つかったタスクファイルをReadツールで読み込み +1. **追加ルールの読み込み** + - `docs/rule` ディレクトリが存在する場合は読み込み + - `docs/rule/kairo` ディレクトリが存在する場合は読み込み + - `docs/rule/kairo/implement` ディレクトリが存在する場合は読み込み + - 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用 + +2. **技術スタック定義の読み込み** + - `docs/tech-stack.md` が存在する場合は読み込み + - 存在しない場合は `CLAUDE.md` から技術スタックセクションを読み込み + - どちらも存在しない場合は `.claude/commands/tech-stack.md` のデフォルト定義を使用 + +3. **タスクの選択** + - @agent-symbol-searcher で指定されたタスクID(TASK-0000形式)を検索し、見つかったタスクファイルをReadツールで読み込み - ユーザが指定したタスクIDを確認 - 指定がない場合は、依存関係に基づいて次のタスクを自動選択 - 選択したタスクの詳細を表示 + - 読み込んだ技術スタック定義に基づいて実装方針を決定 -2. **依存関係の確認** +4. **依存関係の確認** - @agent-symbol-searcher で依存タスクの状態を検索し、見つかったタスクファイルをReadツールで読み込み - 依存タスクが完了しているか確認 - 未完了の依存タスクがある場合は警告 -3. **実装ディレクトリの準備** +5. **実装ディレクトリの準備** - 現在のワークスペースで作業を行う - 必要に応じてディレクトリ構造を確認 -4. **実装タイプの判定** +6. **実装タイプの判定** - タスクの性質を分析（コード実装 vs 準備作業） - 実装方式を決定（TDD vs 直接作業） -5. **実装プロセスの実行** +7. **実装プロセスの実行** ### A. **TDDプロセス**（コード実装タスク用） @@ -97,7 +111,7 @@ description: 分割されたタスクを順番に、またはユーザが指定 ### B. **直接作業プロセス**（準備作業タスク用） - a. **準備作業の実行** - `@task general-purpose direct-work-execute` + a. **準備作業の実行** - `@task general-purpose direct-setup.md` ``` Task実行: 直接作業実行フェーズ 目的: ディレクトリ作成、設定ファイル作成、依存関係のインストール、環境設定を行う @@ -109,7 +123,7 @@ description: 分割されたタスクを順番に、またはユーザが指定 実行方式: 個別Task実行 ``` - b. **作業結果の確認** - `@task general-purpose direct-work-verify` + b. **作業結果の確認** - `@task general-purpose direct-verify.md` ``` Task実行: 直接作業確認フェーズ 目的: 作業完了の検証と成果物確認を行う @@ -120,7 +134,7 @@ description: 分割されたタスクを順番に、またはユーザが指定 実行方式: 個別Task実行 ``` -6. **タスクの完了処理** +8. **タスクの完了処理** - タスクのステータスを更新（タスクファイルのチェックボックスにチェックを入れる） - 実装結果をドキュメント化 - 次のタスクを提案 @@ -162,7 +176,7 @@ flowchart TD $ claude code kairo-implement --all # 特定のタスクを実装 -$ claude code kairo-implement --task TASK-101 +$ claude code kairo-implement --task {{task_id}} # 並行実行可能なタスクを一覧表示 $ claude code kairo-implement --list-parallel @@ -219,8 +233,8 @@ $ claude code kairo-implement --status @task general-purpose tdd-verify-complete.md # 直接作業プロセスの場合 -@task general-purpose direct-work-execute -@task general-purpose direct-work-verify +@task general-purpose direct-setup.md +@task general-purpose direct-verify.md ``` ## 実装時の注意事項 @@ -258,11 +272,11 @@ $ claude code kairo-implement --status ### タスク開始時（TDDプロセス） ``` -🚀 タスク TASK-101: ユーザー認証API の実装を開始します +🚀 タスク {{task_id}}: {{task_name}} の実装を開始します 📋 タスク詳細: - 要件: REQ-101, REQ-102 -- 依存: TASK-002 ✅ +- 依存: {{依存タスクID}} ✅ - 推定時間: 4時間 - 実装タイプ: TDDプロセス @@ -272,11 +286,11 @@ $ claude code kairo-implement --status ### タスク開始時（直接作業プロセス） ``` -🚀 タスク TASK-003: データベース設定 の実装を開始します +🚀 タスク {{task_id}}: {{task_name}} の実装を開始します 📋 タスク詳細: - 要件: REQ-402, REQ-006 -- 依存: TASK-001 ✅ +- 依存: {{依存タスクID}} ✅ - 推定時間: 3時間 - 実装タイプ: 直接作業プロセス @@ -287,7 +301,7 @@ $ claude code kairo-implement --status ``` ✅ Task 1/6: @task tdd-requirements 完了 - ファイル: docs/implements/TASK-101/{要件名}-requirements.md + ファイル: docs/implements/{要件名}/{{task_id}}/{要件名}-requirements.md Task実行結果: 要件定義書作成完了 🏃 Task 2/6: @task tdd-testcases 実行中... @@ -308,7 +322,7 @@ $ claude code kairo-implement --status ### タスク完了時（TDD） ``` -🎉 タスク TASK-101 が完了しました！ +🎉 タスク {{task_id}} が完了しました！ ✅ タスクファイルのチェックボックスを更新しました - [ ] **タスク完了** → [x] **タスク完了** @@ -322,8 +336,8 @@ $ claude code kairo-implement --status - 所要時間: 3時間45分 📝 次の推奨タスク: -- TASK-102: ユーザー管理API -- TASK-201: ログイン画面（依存関係あり） +- {{次のタスクID}}: {{次のタスク名}} +- {{関連タスクID}}: {{関連タスク名}}（依存関係あり） 続けて実装しますか？ (y/n) ``` @@ -331,7 +345,7 @@ $ claude code kairo-implement --status ### タスク完了時（直接作業） ``` -🎉 タスク TASK-003 が完了しました！ +🎉 タスク {{task_id}} が完了しました！ ✅ タスクファイルのチェックボックスを更新しました - [ ] **タスク完了** → [x] **タスク完了** @@ -345,8 +359,8 @@ $ claude code kairo-implement --status - 所要時間: 2時間30分 📝 次の推奨タスク: -- TASK-004: 状態管理設定 -- TASK-101: TaskService実装（依存関係あり） +- {{次のタスクID}}: {{次のタスク名}} +- {{関連タスクID}}: {{関連タスク名}}（依存関係あり） 続けて実装しますか？ (y/n) ``` diff --git a/commands/kairo-requirements.md b/commands/kairo-requirements.md index 5f41581..3a08717 100644 --- a/commands/kairo-requirements.md +++ b/commands/kairo-requirements.md @@ -6,50 +6,117 @@ description: ユーザから提供された要件の概要を分析し、EARS（ ## 目的 -ユーザから提供された要件の概要を分析し、EARS（Easy Approach to Requirements Syntax）記法を使用して詳細な受け入れ基準を含む要件定義書を作成する。 +既存プロジェクトの情報を収集・分析し、ユーザから要件をヒアリングして、EARS（Easy Approach to Requirements Syntax）記法を使用した詳細な受け入れ基準を含む要件定義書を作成する。 +ユーザに要件をヒアリングするときは一問一答形式で選択肢から選ぶか自由入力を可能にする ## 前提条件 -- ユーザから要件の概要が提供されている +- 既存プロジェクト（コードベース、設計文書等）が存在する - `docs/spec/` ディレクトリが存在する（なければ作成） -## 実行内容 +## 実行フロー + +### Phase 0: 既存プロジェクト情報の網羅的収集 **【信頼性レベル指示】**: -各項目について、元の資料（EARS要件定義書・設計文書含む）との照合状況を以下の信号でコメントしてください： - -- 🟢 **青信号**: EARS要件定義書・設計文書を参考にしてほぼ推測していない場合 -- 🟡 **黄信号**: EARS要件定義書・設計文書から妥当な推測の場合 -- 🔴 **赤信号**: EARS要件定義書・設計文書にない推測の場合 - -1. **要件の分析** - - ユーザから提供された要件の概要を理解する - - @agent-symbol-searcher で関連する既存要件・設計文書を検索し、見つかったファイルをReadツールで読み込み - - 関連するドメイン知識を適用する - - 不明確な点がある場合は、一般的なベストプラクティスに基づいて補完する - -2. **ユーザストーリーの作成** - - WHO（誰が）、WHAT（何を）、WHY（なぜ）の形式で記述 - - 各機能の価値を明確にする - -3. **EARS記法による要件定義** - - **通常要件（SHALL）**: システムが通常実行すべき動作 - - **条件付き要件（WHEN/IF-THEN）**: 特定の条件下での動作 - - **不要要件（WHERE）**: 特定の状態での動作 - - **オプション要件（MAY）**: 任意の機能 - - **制約要件（MUST）**: システムの制約事項 - -4. **Edgeケースの定義** - - 異常系の処理 - - 境界値の処理 - - エラーハンドリング - - パフォーマンス要件 - -5. **ファイルの作成** - - `docs/spec/{要件名}-requirements.md`: 機能要件と関連文書へのリンク - - `docs/spec/{要件名}-user-stories.md`: 詳細なユーザストーリー - - `docs/spec/{要件名}-acceptance-criteria.md`: 受け入れ基準とテスト項目 - - マークダウン形式で構造化された文書を作成 +各項目について、元の資料（EARS要件定義書・設計文書・ユーザヒアリング含む）との照合状況を以下の信号でコメントしてください： + +- 🔵 **青信号**: EARS要件定義書・設計文書・ユーザヒアリングを参考にしてほぼ推測していない場合 +- 🟡 **黄信号**: EARS要件定義書・設計文書・ユーザヒアリングから妥当な推測の場合 +- 🔴 **赤信号**: EARS要件定義書・設計文書・ユーザヒアリングにない推測の場合 + +1. **追加ルールの読み込み** + - `docs/rule` ディレクトリが存在する場合は読み込み + - `docs/rule/kairo` ディレクトリが存在する場合は読み込み + - `docs/rule/kairo/requirements` ディレクトリが存在する場合は読み込み + - 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用 + +2. **プロジェクト基本情報収集** + - `CLAUDE.md` の内容を読み込み（プロジェクト概要・技術スタック・制約） + - `README.md` が存在する場合は読み込み + - プロジェクト構造（ディレクトリ構成）を把握 + +3. **既存設計文書・仕様書の調査** + - `docs/` ディレクトリ配下の全設計文書を確認 + - 既存の要件定義書・設計書を読み込み + - タスク管理ファイル（phase*.md）の内容確認 + - API仕様書・DB設計書があれば確認 + +4. **既存コードベース・開発状況の分析** + - @agent-symbol-searcher で既存仕様・実装の網羅的調査 + - git status/log で現在の開発状況・進捗確認 + - 実装済み機能 vs 設計書の差分分析 + - 残タスク・未実装部分の特定 + +5. **収集情報のサマリー作成** + - 既存プロジェクトの全体像整理 + - 定義済み要件・未定義部分の特定 + - 技術制約・非機能要件の整理 + - ギャップ分析（設計 vs 実装 vs ユーザー期待） + +### Phase 1: 既存情報ベースの差分ヒアリング + +6. **既存設計の妥当性・過不足確認** + - 既存の機能要件・非機能要件の確認質問 + - 現在の制約事項（性能・データ制限等）の妥当性確認 + - 技術スタック選択の再確認 + - 既存設計で実現困難・不適切な部分の特定 + +7. **未定義・曖昧部分の詳細化ヒアリング** + - 設計文書で詳細が不明な機能の具体化 + - ユーザーの実際の業務フロー・ユースケースの確認 + - 入出力データの詳細仕様確認 + - UI/UX の具体的な期待値確認 + +8. **追加・変更要件の特定** + - 既存設計にない新規機能要件の聞き出し + - 外部システム連携の追加需要確認 + - レポート・分析機能等の追加需要確認 + - 運用・メンテナンス要件の追加確認 + +9. **既存機能への影響範囲確認** + - 新規要件による既存機能への影響許容度確認 + - パフォーマンス要件への影響確認 + - セキュリティ・アクセシビリティ要件への影響確認 + - データ移行・互換性要件の確認 + +10. **優先順位・スコープ調整** + - Must Have / Should Have / Could Have / Won't Have の分類 + - リリーススコープ・段階的リリース計画の確認 + - 予算・スケジュール制約に基づく優先順位調整 + +### Phase 2: 統合要件定義書作成 + +11. **ユーザストーリーの作成・更新** + - WHO（誰が）、WHAT（何を）、WHY（なぜ）の形式で記述 + - 既存ユーザストーリーの更新・新規ストーリーの追加 + - 各機能の価値・優先順位を明確化 + +12. **EARS記法による統合要件定義** + - **通常要件（SHALL）**: システムが通常実行すべき動作 + - **条件付き要件（WHEN/IF-THEN）**: 特定の条件下での動作 + - **不要要件（WHERE）**: 特定の状態での動作 + - **オプション要件（MAY）**: 任意の機能 + - **制約要件（MUST）**: システムの制約事項 + - 既存要件との統合・重複排除・矛盾解決 + +13. **Edgeケース・非機能要件の定義** + - 異常系の処理・エラーハンドリング + - 境界値の処理・データ制限 + - パフォーマンス・セキュリティ・ユーザビリティ要件 + - 運用・保守・移行要件 + +14. **統合要件定義書ファイルの作成** + - `docs/spec/{要件名}-requirements.md`: 統合機能要件と関連文書へのリンク + - `docs/spec/{要件名}-user-stories.md`: 詳細なユーザストーリー + - `docs/spec/{要件名}-acceptance-criteria.md`: 受け入れ基準とテスト項目 + - 既存要件からの変更点・追加点を明記 + **【信頼性レベル指示】**: + 各項目について、元の資料（EARS要件定義書・設計文書・ユーザヒアリング含む）との照合状況を以下の信号でコメントしてください： + + - 🔵 **青信号**: EARS要件定義書・設計文書・ユーザヒアリングを参考にしてほぼ推測していない場合 + - 🟡 **黄信号**: EARS要件定義書・設計文書・ユーザヒアリングから妥当な推測の場合 + - 🔴 **赤信号**: EARS要件定義書・設計文書・ユーザヒアリングにない推測の場合 ## 出力フォーマット例 @@ -69,51 +136,59 @@ description: ユーザから提供された要件の概要を分析し、EARS（ ## 機能要件（EARS記法） +**【信頼性レベル凡例】**: +- 🔵 **青信号**: EARS要件定義書・設計文書・ユーザヒアリングを参考にした確実な要件 +- 🟡 **黄信号**: EARS要件定義書・設計文書・ユーザヒアリングから妥当な推測による要件 +- 🔴 **赤信号**: EARS要件定義書・設計文書・ユーザヒアリングにない推測による要件 + ### 通常要件 -- REQ-001: システムは {通常の動作} しなければならない -- REQ-002: システムは {通常の動作} しなければならない +- REQ-001: システムは {通常の動作} しなければならない 🔵 *EARS要件定義書第3章より* +- REQ-002: システムは {通常の動作} しなければならない 🟡 *設計文書から妥当な推測* +- REQ-003: システムは {通常の動作} しなければならない 🔵 *ユーザヒアリング2024-01-15より* ### 条件付き要件 -- REQ-101: {条件} の場合、システムは {動作} しなければならない -- REQ-102: {条件} の場合、システムは {動作} しなければならない +- REQ-101: {条件} の場合、システムは {動作} しなければならない 🔵 *ユーザー要件・API仕様書より* +- REQ-102: {条件} の場合、システムは {動作} しなければならない 🔴 *設計文書にない推測* +- REQ-103: {条件} の場合、システムは {動作} しなければならない 🟡 *ユーザヒアリング内容から妥当な推測* ### 状態要件 -- REQ-201: {状態} にある場合、システムは {動作} しなければならない +- REQ-201: {状態} にある場合、システムは {動作} しなければならない 🟡 *DB設計書から妥当な推測* ### オプション要件 -- REQ-301: システムは {オプション機能} してもよい +- REQ-301: システムは {オプション機能} してもよい 🔵 *CLAUDE.md技術制約より* ### 制約要件 -- REQ-401: システムは {制約事項} しなければならない +- REQ-401: システムは {制約事項} しなければならない 🔵 *CLAUDE.md・既存実装より* ## 非機能要件 ### パフォーマンス -- NFR-001: {パフォーマンス要件} +- NFR-001: {パフォーマンス要件} 🟡 *CLAUDE.md制約から妥当な推測* ### セキュリティ -- NFR-101: {セキュリティ要件} +- NFR-101: {セキュリティ要件} 🔵 *セキュリティ設計書・実装より* ### ユーザビリティ -- NFR-201: {ユーザビリティ要件} +- NFR-201: {ユーザビリティ要件} 🔴 *ユーザー要件にない推測* +- NFR-202: {ユーザビリティ要件} 🔵 *ユーザヒアリング2024-01-20 UX要望より* ## Edgeケース ### エラー処理 -- EDGE-001: {エラーケース} +- EDGE-001: {エラーケース} 🟡 *既存実装から妥当な推測* ### 境界値 -- EDGE-101: {境界値ケース} +- EDGE-101: {境界値ケース} 🔵 *API仕様書・テストケースより* ``` ### 2. user-stories.md（詳細なユーザストーリー） @@ -140,9 +215,14 @@ description: ユーザから提供された要件の概要を分析し、EARS（ ## ユーザストーリー -### 📚 エピック1: {大きな機能グループ} +**【信頼性レベル凡例】**: +- 🔵 **青信号**: EARS要件定義書・設計文書・ユーザヒアリングを参考にした確実なストーリー +- 🟡 **黄信号**: EARS要件定義書・設計文書・ユーザヒアリングから妥当な推測によるストーリー +- 🔴 **赤信号**: EARS要件定義書・設計文書・ユーザヒアリングにない推測によるストーリー -#### ストーリー1.1: {具体的なストーリー名} +### 📚 エピック1: {大きな機能グループ} 🔵 *ユーザヒアリング2024-01-15より* + +#### ストーリー1.1: {具体的なストーリー名} 🔵 *EARS要件定義書・ユーザヒアリングより* **ユーザストーリー**: - **私は** {ユーザー種別} **として** @@ -162,17 +242,17 @@ description: ユーザから提供された要件の概要を分析し、EARS（ **見積もり**: {ストーリーポイントまたは工数} -#### ストーリー1.2: {具体的なストーリー名} +#### ストーリー1.2: {具体的なストーリー名} 🟡 *設計文書から妥当な推測* {同様の形式で記載} -### 📚 エピック2: {大きな機能グループ} +### 📚 エピック2: {大きな機能グループ} 🔴 *既存資料にない推測* {同様の形式で記載} ## ユーザージャーニー -### ジャーニー1: {代表的な利用フロー} +### ジャーニー1: {代表的な利用フロー} 🔵 *ユーザヒアリング業務フローより* ```mermaid journey @@ -191,7 +271,7 @@ journey ## ペルソナ定義 -### ペルソナ1: {代表的ユーザー名} +### ペルソナ1: {代表的ユーザー名} 🔵 *ユーザヒアリング2024-01-18 ペルソナ調査より* - **基本情報**: {年齢、職業、技術レベル等} - **ゴール**: {このユーザーが達成したいこと} @@ -228,7 +308,12 @@ journey ## 機能テスト基準 -### REQ-001: {要件名} の受け入れ基準 +**【信頼性レベル凡例】**: +- 🔵 **青信号**: EARS要件定義書・設計文書・ユーザヒアリングを参考にした確実なテスト基準 +- 🟡 **黄信号**: EARS要件定義書・設計文書・ユーザヒアリングから妥当な推測によるテスト基準 +- 🔴 **赤信号**: EARS要件定義書・設計文書・ユーザヒアリングにない推測によるテスト基準 + +### REQ-001: {要件名} の受け入れ基準 🔵 *EARS要件定義書・既存テスト仕様より* **Given（前提条件）**: - {テスト実行前の状態} @@ -247,7 +332,7 @@ journey - [ ] 異常系: {異常なケースの詳細} - [ ] 境界値: {境界値テストの詳細} -### REQ-002: {要件名} の受け入れ基準 +### REQ-002: {要件名} の受け入れ基準 🟡 *ユーザヒアリング要望から妥当な推測* {同様の形式で記載} @@ -255,7 +340,7 @@ journey ### パフォーマンステスト -**NFR-001: {パフォーマンス要件}** +**NFR-001: {パフォーマンス要件} 🔵 *CLAUDE.md制約・ユーザヒアリングより*** - [ ] 応答時間: {具体的な時間基準} - [ ] スループット: {処理量の基準} @@ -269,7 +354,7 @@ journey ### セキュリティテスト -**NFR-101: {セキュリティ要件}** +**NFR-101: {セキュリティ要件} 🟡 *セキュリティ設計書から妥当な推測*** - [ ] 認証: {認証機能のテスト項目} - [ ] 認可: {権限制御のテスト項目} @@ -292,7 +377,7 @@ journey ## Edgeケーステスト基準 -### EDGE-001: {エラーケース} の受け入れ基準 +### EDGE-001: {エラーケース} の受け入れ基準 🔴 *既存資料にない推測* **テストシナリオ**: - {異常な状況の設定} @@ -345,13 +430,44 @@ journey - [ ] ステークホルダーへの報告 ``` +## ヒアリング質問例 + +### 既存設計確認系質問 + +- "現在のCLAUDE.mdで定義されている{制約事項}について、実際の運用で問題ないでしょうか？" +- "技術スタック（{技術名}）について、変更希望や追加制約はありますか？" +- "既存の{機能名}機能で、想定しているユースケースに追加はありますか？" +- "パフォーマンス要件（{具体的な数値}）で、実際の業務に支障はないでしょうか？" + +### 詳細化系質問 + +- "{機能名}で、具体的にどのような操作フローを想定していますか？" +- "データの入力項目について、{項目名}以外に必要なものはありますか？" +- "エラーが発生した場合、どのような通知・対応を期待しますか？" +- "外部システムとの連携で、{システム名}との接続は必要ですか？" + +### 追加要件系質問 + +- "現在の設計にない機能で、実現したいものはありますか？" +- "レポート・分析機能は必要ですか？必要な場合、どのような情報が欲しいですか？" +- "モバイルアプリでの利用は想定していますか？" +- "複数人での同時利用・権限管理は必要ですか？" + +### 影響確認系質問 + +- "この新機能により、既存の{機能名}の変更は許容できますか？" +- "データ移行が発生する場合、どの程度の作業時間が許容できますか？" +- "パフォーマンスへの影響で、許容できる範囲を教えてください" +- "セキュリティ要件で、追加で考慮すべき点はありますか？" + ## 実行後の確認 -- @agent-symbol-searcher で作成した要件との関連性を確認 +- Phase 0で収集した既存プロジェクト情報のサマリーを表示 +- Phase 1でのヒアリング結果と既存情報との差分を明確化 - 作成した3つのファイルのパスを表示 - `docs/spec/{要件名}-requirements.md` - `docs/spec/{要件名}-user-stories.md` - `docs/spec/{要件名}-acceptance-criteria.md` -- 主要な要件の数とユーザストーリー数を報告 +- 既存要件からの変更点・追加点の件数を報告 - 各ファイル内のリンクが正しく設定されていることを確認 -- ユーザに確認を促すメッセージを表示 +- 既存設計書・実装との整合性確認を促すメッセージを表示 diff --git a/commands/kairo-task-verify.md b/commands/kairo-task-verify.md index d64d713..b13db42 100644 --- a/commands/kairo-task-verify.md +++ b/commands/kairo-task-verify.md @@ -18,20 +18,31 @@ description: 作成されたタスクファイルの内容を確認し、出力 **【信頼性レベル指示】**: 各項目について、元の資料（EARS要件定義書・設計文書含む）との照合状況を以下の信号でコメントしてください： -- 🟢 **青信号**: EARS要件定義書・設計文書を参考にしてほぼ推測していない場合 +- 🔵 **青信号**: EARS要件定義書・設計文書を参考にしてほぼ推測していない場合 - 🟡 **黄信号**: EARS要件定義書・設計文書から妥当な推測の場合 - 🔴 **赤信号**: EARS要件定義書・設計文書にない推測の場合 -1. **タスクファイルの確認** +1. **追加ルールの読み込み** + - `docs/rule` ディレクトリが存在する場合は読み込み + - `docs/rule/kairo` ディレクトリが存在する場合は読み込み + - `docs/rule/kairo/task-verify` ディレクトリが存在する場合は読み込み + - 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用 + +2. **技術スタック定義の読み込み** + - `docs/tech-stack.md` が存在する場合は読み込み + - 存在しない場合は `CLAUDE.md` から技術スタックセクションを読み込み + - どちらも存在しない場合は `.claude/commands/tech-stack.md` のデフォルト定義を使用 + +3. **タスクファイルの確認** - @agent-symbol-searcher でタスクファイルを検索し、見つかったファイルをReadツールで読み込み - `docs/tasks/{要件名}-tasks.md` をReadツールで読み込み -2. **出力フォーマット例との比較** +4. **出力フォーマット例との比較** - @agent-symbol-searcher で関連するタスクフォーマットを検索し、見つかったファイルをReadツールで読み込み - kairo-tasksコマンドファイルをReadツールで読み込み、出力フォーマット例を確認 - 作成されたタスクファイルに不足している情報を特定 -3. **不足情報の追加** +5. **不足情報の追加** 以下の項目が含まれているか確認し、不足していれば追加： - 概要セクション（全タスク数、推定作業時間、クリティカルパス） - 各タスクのチェックボックス @@ -46,7 +57,7 @@ description: 作成されたタスクファイルの内容を確認し、出力 - 実行順序（Mermaidガントチャート） - サブタスクテンプレート情報 -4. **ファイルの更新** +6. **ファイルの更新** - 不足している情報を追加してファイルを更新 ## 実行後の確認 diff --git a/commands/kairo-tasks.md b/commands/kairo-tasks.md index f18f677..9fcd071 100644 --- a/commands/kairo-tasks.md +++ b/commands/kairo-tasks.md @@ -13,44 +13,59 @@ description: 設計文書に基づいて実装タスクを1日単位の粒度で - `docs/design/{要件名}/` に設計文書が存在する - 設計がユーザによって承認されている（または承認が省略されている） - `docs/tasks/` ディレクトリが存在する（なければ作成） +- 思考は英語で実施。ファイルは日本語で記述 +- NEVER: task_id は　`TASK-{4桁の数字}` (例 TASK-0001 )にする ## 実行内容 **【信頼性レベル指示】**: 各項目について、元の資料（EARS要件定義書・設計文書含む）との照合状況を以下の信号でコメントしてください： -- 🟢 **青信号**: EARS要件定義書・設計文書を参考にしてほぼ推測していない場合 +- 🔵 **青信号**: EARS要件定義書・設計文書を参考にしてほぼ推測していない場合 - 🟡 **黄信号**: EARS要件定義書・設計文書から妥当な推測の場合 - 🔴 **赤信号**: EARS要件定義書・設計文書にない推測の場合 -1. **設計文書の分析** +1. **追加ルールの読み込み** + - `docs/rule` ディレクトリが存在する場合は読み込み + - `docs/rule/kairo` ディレクトリが存在する場合は読み込み + - `docs/rule/kairo/tasks` ディレクトリが存在する場合は読み込み + - 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用 + +2. **技術スタック定義の読み込み** + - `docs/tech-stack.md` が存在する場合は読み込み + - 存在しない場合は `CLAUDE.md` から技術スタックセクションを読み込み + - どちらも存在しない場合は `.claude/commands/tech-stack.md` のデフォルト定義を使用 + +3. **設計文書の分析** - @agent-symbol-searcher で設計文書を検索し、見つかったファイルをReadツールで読み込み - `docs/design/{要件名}/architecture.md` をReadツールで読み込み - `docs/design/{要件名}/database-schema.sql` をReadツールで読み込み - `docs/design/{要件名}/api-endpoints.md` をReadツールで読み込み - `docs/design/{要件名}/interfaces.ts` をReadツールで読み込み - `docs/design/{要件名}/dataflow.md` をReadツールで読み込み + - 読み込んだ技術スタック定義に基づいて実装技術を特定 -2. **既存タスクファイルの確認** +4. **既存タスクファイルの確認** - @agent-symbol-searcher で既存タスクIDを検索し、見つかったタスクファイルをReadツールで読み込み - 既存の`docs/tasks/{要件名}-*.md`ファイルをReadツールで読み込み - - 使用済みタスク番号（TASK-0001形式）を抽出 + - 使用済みタスク番号（TASK-0000形式）を抽出 - 新規タスクで重複しない番号を割り当て -3. **タスクの洗い出し** +5. **タスクの洗い出し** - 基盤タスク（DB設定、環境構築など） - バックエンドタスク（API実装） - フロントエンドタスク（UI実装） + - 画面のグループ毎に細かく分割する - 統合タスク（E2Eテストなど） -4. **依存関係の分析** +6. **依存関係の分析** - タスク間の依存関係を明確化 - 並行実行可能なタスクを識別 - クリティカルパスを特定 -5. **タスクの詳細化** +7. **タスクの詳細化** 各タスクに以下を含める： - - タスクID（TASK-0001形式の4桁番号） + - タスクID（TASK-0000形式） - タスク名 - タスクタイプ（TDD/DIRECT） - **TDD**: コーディング、ビジネスロジック実装、UI実装、テスト実装など開発作業 @@ -66,329 +81,89 @@ description: 設計文書に基づいて実装タスクを1日単位の粒度で - モバイル対応 - アクセシビリティ要件 -6. **タスクの順序付け** +8. **タスクの順序付け** - 依存関係に基づいて実行順序を決定 - マイルストーンを設定 - 並行実行可能なタスクをグループ化 -7. **フェーズ分割とファイル作成** - - タスクを1ヶ月程度の期間でフェーズに分割 - - 各フェーズ毎に個別のタスクファイルを作成 - - `docs/tasks/{要件名}-overview.md`: 全体概要とフェーズ一覧 +9. **フェーズ分割** + - 各タスクを1日単位の粒度で設計 + - タスクを1ヶ月(20日想定)以内の期間でフェーズに分割 + - NEVER タスクの情報の省略 + - YOU MUST 180時間を超えるようなフェーズは分割する + - IMPORTANT フェーズ数は固定しない + - IMPORTANT フェーズは500行未満で分割する + - YOU MUST フェーズの分割はアーキテクチャのレイヤーを基準にする + - NEVER 事前検討した分割基準を前提としない + +10. **ファイル作成** + - ファイル作成は ファイル毎に @task で実行する + - 各フェーズ毎に個別のタスクファイルを日本語で作成 + - NEVER タスクの情報の省略 - `docs/tasks/{要件名}-phase1.md`: フェーズ1の詳細タスク - `docs/tasks/{要件名}-phase2.md`: フェーズ2の詳細タスク - （以下、フェーズ数に応じて継続） - - 各タスクを1日単位の粒度で設計 + - `docs/tasks/{要件名}-overview.md`: 全体概要とフェーズ一覧 - 各タスクにチェックボックスを追加してタスクの完了状況を追跡可能にする - -## 出力フォーマット例 - -### 1. overview.md（全体概要） - -````markdown -# {要件名} 実装タスク全体概要 - -## プロジェクト概要 - -- **要件名**: {要件名} -- **総期間**: {開始日} 〜 {終了予定日} -- **総工数**: {工数} -- **総タスク数**: {数} - -## フェーズ構成 - -| フェーズ | 期間 | 主要成果物 | タスク数 | 工数 | ファイル | -|---------|------|-----------|---------|------|---------| -| Phase 1: 基盤構築 | 1ヶ月 | 開発環境・DB設定 | 20タスク | 160h | [phase1.md](phase1.md) | -| Phase 2: コア機能 | 1ヶ月 | 基本API・認証 | 22タスク | 176h | [phase2.md](phase2.md) | -| Phase 3: UI実装 | 1ヶ月 | 画面・コンポーネント | 25タスク | 200h | [phase3.md](phase3.md) | -| Phase 4: 統合・最適化 | 2週間 | テスト・性能調整 | 10タスク | 80h | [phase4.md](phase4.md) | - -## 既存タスク番号の管理 - -**既存ファイル確認結果**: -- 確認したファイル: `docs/tasks/{要件名}-*.md` -- 使用済みタスク番号: TASK-0001 〜 TASK-0077 (例) -- 次回開始番号: TASK-0078 - -## 依存関係 - -```mermaid -gantt - title プロジェクト全体スケジュール - dateFormat YYYY-MM-DD - section Phase 1 - 基盤構築 :phase1, 2024-01-01, 30d - section Phase 2 - コア機能 :phase2, after phase1, 30d - section Phase 3 - UI実装 :phase3, after phase2, 30d - section Phase 4 - 統合・最適化 :phase4, after phase3, 14d -``` - -## 進捗管理 - -### 全体進捗 -- [ ] Phase 1: 基盤構築 (0/20) -- [ ] Phase 2: コア機能 (0/22) -- [ ] Phase 3: UI実装 (0/25) -- [ ] Phase 4: 統合・最適化 (0/10) - -### マイルストーン -- [ ] M1: 開発環境完成 (Phase 1完了時) -- [ ] M2: MVP機能完成 (Phase 2完了時) -- [ ] M3: UI完成 (Phase 3完了時) -- [ ] M4: リリース準備完了 (Phase 4完了時) - -## リスク管理 - -| リスク | 影響度 | 発生確率 | 対策 | -|--------|--------|----------|------| -| {リスク項目} | 高/中/低 | 高/中/低 | {対策内容} | - -## 品質基準 - -- テストカバレッジ: 90%以上 -- パフォーマンス: 応答時間3秒以内 -- セキュリティ: OWASP Top 10対応 -- アクセシビリティ: WCAG 2.1 AA準拠 -```` - -### 2. phase*.md（各フェーズ詳細） - -````markdown -# {要件名} Phase 1: 基盤構築 - -## フェーズ概要 - -- **期間**: 1ヶ月 (20営業日) -- **目標**: 開発環境とデータベース基盤の構築 -- **成果物**: 動作する開発環境、データベーススキーマ、CI/CD基盤 -- **担当**: {担当者名} - -## 週次計画 - -### Week 1: 環境構築 -- **目標**: 基本的な開発環境の構築 -- **成果物**: Docker環境、基本設定 - -### Week 2: データベース設計 -- **目標**: データベーススキーマの実装 -- **成果物**: DB設計、マイグレーション - -### Week 3: CI/CD構築 -- **目標**: 自動化パイプラインの構築 -- **成果物**: テスト・デプロイ自動化 - -### Week 4: 基盤テスト・調整 -- **目標**: 基盤の安定化 -- **成果物**: 動作確認済み基盤 - -## 日次タスク - -### Week 1: 環境構築 - -#### Day 1 (TASK-0001): プロジェクト初期化 - -- [ ] **タスク完了** -- **推定工数**: 8時間 -- **タスクタイプ**: DIRECT -- **要件リンク**: REQ-001 -- **依存タスク**: なし -- **実装詳細**: - - Node.js/TypeScript環境設定 - - package.json設定 - - ESLint/Prettier設定 - - Git初期化・.gitignore設定 -- **完了条件**: - - [ ] npm run dev で開発サーバーが起動する - - [ ] npm run lint でエラーが出ない - - [ ] TypeScript設定が正しく動作する -- **注意事項**: Node.js LTS版を使用すること - -#### Day 2 (TASK-0002): Docker環境構築 - -- [ ] **タスク完了** -- **推定工数**: 8時間 -- **タスクタイプ**: DIRECT -- **要件リンク**: REQ-002 -- **依存タスク**: TASK-0001 -- **実装詳細**: - - Dockerfile作成 - - docker-compose.yml設定 - - PostgreSQL・Redis設定 - - 環境変数管理設定 -- **完了条件**: - - [ ] docker-compose up で全サービスが起動する - - [ ] アプリケーションからDB接続できる - - [ ] ホットリロードが動作する -- **注意事項**: ポート競合に注意すること - -#### Day 3 (TASK-0003): 基本ディレクトリ構造 - -- [ ] **タスク完了** -- **推定工数**: 6時間 -- **タスクタイプ**: DIRECT -- **要件リンク**: REQ-003 -- **依存タスク**: TASK-0002 -- **実装詳細**: - - src/ディレクトリ構造作成 - - テストディレクトリ構造 - - 設定ファイル配置 - - README.md作成 -- **完了条件**: - - [ ] Clean Architectureに沿った構造 - - [ ] テストファイルの配置が正しい - - [ ] README.mdが充実している -- **注意事項**: 後から変更しにくい構造のため慎重に設計 - -#### Day 4 (TASK-0004): ログ・エラーハンドリング基盤 - -- [ ] **タスク完了** -- **推定工数**: 8時間 -- **タスクタイプ**: TDD -- **要件リンク**: REQ-004 -- **依存タスク**: TASK-0003 -- **実装詳細**: - - Winston/Pinoログライブラリ設定 - - エラーハンドリングミドルウェア - - 構造化ログ設定 - - ログローテーション設定 -- **テスト要件**: - - [ ] ログ出力テスト - - [ ] エラーハンドリングテスト - - [ ] ログレベル制御テスト -- **完了条件**: - - [ ] 各レベルのログが正しく出力される - - [ ] エラーが適切にキャッチされる - - [ ] 本番環境でセンシティブ情報が出力されない - -#### Day 5 (TASK-0005): 設定管理システム - -- [ ] **タスク完了** -- **推定工数**: 6時間 -- **タスクタイプ**: TDD -- **要件リンク**: REQ-005 -- **依存タスク**: TASK-0004 -- **実装詳細**: - - 環境別設定ファイル - - 設定バリデーション - - 機密情報管理 - - 設定読み込みモジュール -- **テスト要件**: - - [ ] 設定読み込みテスト - - [ ] 環境別設定テスト - - [ ] 設定バリデーションテスト -- **完了条件**: - - [ ] 環境変数が正しく読み込まれる - - [ ] 不正な設定でエラーになる - - [ ] 機密情報が適切に管理される - -### Week 2: データベース設計 - -#### Day 6 (TASK-0006): データベース接続基盤 - -- [ ] **タスク完了** -- **推定工数**: 8時間 -- **タスクタイプ**: TDD -- **要件リンク**: REQ-401 -- **依存タスク**: TASK-0005 -- **実装詳細**: - - TypeORM/Prisma設定 - - 接続プール設定 - - マイグレーション基盤 - - データベースモニタリング -- **テスト要件**: - - [ ] 接続プールテスト - - [ ] 接続障害処理テスト - - [ ] トランザクション管理テスト -- **完了条件**: - - [ ] データベース接続が安定している - - [ ] 接続プールが適切に動作する - - [ ] マイグレーションコマンドが動作する - -{...続き、Day 7-20まで同様の形式で記載...} - -## フェーズ完了基準 - -- [ ] 全タスクが完了している (20/20) -- [ ] 開発環境が安定して動作する -- [ ] データベーススキーマが完成している -- [ ] CI/CDパイプラインが動作する -- [ ] 基盤コードのテストカバレッジが90%以上 -- [ ] セキュリティチェックが完了している -- [ ] ドキュメントが整備されている - -## 次フェーズへの引き継ぎ事項 - -- 開発環境の利用方法 -- データベーススキーマの詳細 -- CI/CDの運用方法 -- 設定項目の一覧 -- トラブルシューティング情報 - -## 振り返り - -### 計画との差異 -- {計画と実際の差異を記録} - -### 学習事項 -- {技術的な学習事項を記録} - -### 改善点 -- {次フェーズで改善すべき点を記録} -```` - -## サブタスクテンプレート - -### TDDタスクの場合 - -各タスクは以下のTDDプロセスで実装: - + - 各タスクには 要件名 の定義を含める + +## 出力ファイル構造 + +作成するファイル: +- `docs/tasks/{要件名}-overview.md`: 全体概要とフェーズ一覧 +- `docs/tasks/{要件名}-phase1.md`: フェーズ1詳細タスク +- `docs/tasks/{要件名}-phase2.md`: フェーズ2詳細タスク +- （フェーズ数に応じて継続） + +## 必須構成要素 + +### Overview.mdの必須項目 +- プロジェクト概要（期間・工数・総タスク数） +- フェーズ構成テーブル（期間・成果物・タスク数・工数・ファイルリンク） +- 既存タスク番号管理（使用済み番号・次回開始番号） +- 全体進捗チェックボックス +- マイルストーン定義 + +### Phase.mdの必須項目 +- フェーズ概要（期間・目標・成果物） +- 週次計画（Week 1-4の目標・成果物） +- 日次タスク（TASK-0000形式、8時間単位） +- 各タスクの詳細構成: + - タスク完了チェックボックス + - 推定工数・タスクタイプ（TDD/DIRECT） + - 要件リンク・依存タスク + - 要件名 + - 実装詳細・完了条件 + - テスト要件（TDDタスクの場合） + +## タスクプロセス定義 + +### TDDタスク 1. `tdd-requirements.md` - 詳細要件定義 -2. `tdd-testcases.md` - テストケース作成 +2. `tdd-testcases.md` - テストケース作成 3. `tdd-red.md` - テスト実装（失敗） 4. `tdd-green.md` - 最小実装 5. `tdd-refactor.md` - リファクタリング 6. `tdd-verify-complete.md` - 品質確認 -### DIRECTタスクの場合 - -各タスクは以下のDIRECTプロセスで実装: - +### DIRECTタスク 1. `direct-setup.md` - 直接実装・設定 2. `direct-verify.md` - 動作確認・品質確認 -``` +## 実行フロー -## 実行後の確認 +1. **追加ルール読み込み**: `docs/rule` → `docs/rule/kairo` → `docs/rule/kairo/tasks` +2. **技術スタック読み込み**: `docs/tech-stack.md` → `CLAUDE.md` → `.claude/commands/tech-stack.md` +3. **設計文書分析**: @agent-symbol-searcher で検索後、Readツールで各ファイル読み込み +4. **既存タスク確認**: @agent-symbol-searcher + Readで使用済み番号抽出 +5. **タスク洗い出し**: 基盤→バックエンド→フロントエンド→統合の順 +6. **フェーズ分割**: 180時間・500行を超えない単位で分割 +7. **ファイル作成**: overview.md + phase*.md作成 -- @agent-symbol-searcher で作成したタスクと既存システムとの整合性を確認 -- 作成したファイルの一覧を表示 - - `docs/tasks/{要件名}-overview.md`: 全体概要とフェーズ一覧 - - `docs/tasks/{要件名}-phase1.md`: フェーズ1詳細 - - `docs/tasks/{要件名}-phase2.md`: フェーズ2詳細 - - （以下、フェーズ数に応じて継続） -- 各フェーズの概要とタスク数を表示 -- 全体スケジュールと依存関係を表示 -- プロジェクト期間と総工数を報告 -- **既存タスク番号の確認結果を表示** - - 既存ファイルから抽出した使用済み番号 - - 新規タスクで使用開始する番号 - - 重複なく連続した番号の割り当て確認 -- ユーザに実装開始の確認を促すメッセージを表示 - -## ファイル間リンクの確認 - -- overview.mdから各phase*.mdへのリンクが正しく設定されていることを確認 -- 各フェーズファイル内のタスク依存関係が正しく記載されていることを確認 -- **全タスクIDがTASK-0001形式の4桁で統一されていることを確認** -- マイルストーンとフェーズ完了基準が明確に定義されていることを確認 - -## タスク番号管理の注意事項 +## 品質基準 -- 既存ファイルがある場合は必ずGrepツールで使用済み番号を確認 -- TASK-0001からTASK-9999まで最大9999タスクをサポート -- 番号の重複や欠番が発生しないよう注意深く管理 -- 複数のフェーズファイルにまたがってもタスク番号は連続で割り当て +- **フェーズ制限**: 180時間以内、500行未満 +- **タスク粒度**: 1日8時間単位 +- **番号管理**: TASK-0000形式、重複なし +- **完了条件**: 各タスクにチェックボックスと完了条件 +- **依存関係**: 前タスク完了後の実行順序明記 diff --git a/commands/tdd-cycle-full.sh b/commands/tdd-cycle-full.sh index 3a22183..4c2799a 100755 --- a/commands/tdd-cycle-full.sh +++ b/commands/tdd-cycle-full.sh @@ -62,9 +62,10 @@ run_tdd_cycle() { fi echo -e "${GREEN}✅ VERIFY COMPLETE フェーズ完了${NC}" + echo -e "${verify_result} # 結果の判定 - if echo "$verify_result" | grep -E "(品質基準を満たしています|実装完了|検証完了)" > /dev/null; then + if echo "$verify_result" | grep -E "(完全性検証: 合格)" > /dev/null; then echo -e "${GREEN}🎉 TDDサイクル完了${NC}: $test_case のTDDサイクルが正常に完了しました" return 0 elif echo "$verify_result" | grep -E "(未実装|品質基準に満たない|追加実装が必要)" > /dev/null; then diff --git a/commands/tdd-green.md b/commands/tdd-green.md index eb773b6..ab03a01 100644 --- a/commands/tdd-green.md +++ b/commands/tdd-green.md @@ -10,16 +10,23 @@ TDDのGreenフェーズを実行します。 開発コンテキストの準備を行います： -1. **@agent-symbol-searcher で実装関連情報を検索し、見つかったファイルを読み込み** +1. **追加ルールの読み込み** + - `AGENTS.md` ファイルが存在する場合は読み込み + - `docs/rule` ディレクトリが存在する場合は読み込み + - `docs/rule/tdd` ディレクトリが存在する場合は読み込み + - `docs/rule/tdd/green` ディレクトリが存在する場合は読み込み + - 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用 + +2. **@agent-symbol-searcher で実装関連情報を検索し、見つかったファイルを読み込み** - 既存の類似機能やユーティリティ関数を検索し、該当ファイルをReadツールで読み込み - 実装パターンやアーキテクチャガイドラインを特定し、設計文書をReadツールで読み込み - 依存関係やインポートパスを確認し、関連ファイルをReadツールで読み込み -2. **関連ファイルを直接読み込み** - - `docs/implements/{{task_id}}/{feature_name}-memo.md` - 既存の開発履歴を確認 - - `docs/implements/{{task_id}}/{feature_name}-requirements.md` - 要件定義を確認 - - `docs/implements/{{task_id}}/{feature_name}-testcases.md` - テストケース定義を確認 - - `docs/implements/{{task_id}}/{feature_name}-red-phase.md` - Redフェーズのテストを確認 +3. **関連ファイルを直接読み込み** + - `docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md` - 既存の開発履歴を確認 + - `docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md` - 要件定義を確認 + - `docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md` - テストケース定義を確認 + - `docs/implements/{要件名}/{{task_id}}/{feature_name}-red-phase.md` - Redフェーズのテストを確認 - 関連する設計文書やタスクファイルも必要に応じて読み込み 読み込み完了後、準備されたコンテキスト情報を基にGreenフェーズ（実装）の作業を開始します。 @@ -30,7 +37,7 @@ TDDのGreenフェーズを実行します。 実装コード作成時には、各実装内容について元の資料との照合状況を以下の信号でコメントしてください： -- 🟢 **青信号**: 元の資料を参考にしてほぼ推測していない場合 +- 🔵 **青信号**: 元の資料を参考にしてほぼ推測していない場合 - 🟡 **黄信号**: 元の資料から妥当な推測の場合 - 🔴 **赤信号**: 元の資料にない推測の場合 @@ -65,7 +72,7 @@ Redフェーズで作成したテストを通すための**実装**を行って * 【機能概要】: [この関数が何をするかを日本語で説明] * 【実装方針】: [なぜこのような実装方法を選んだかを説明] * 【テスト対応】: [どのテストケースを通すための実装かを明記] - * 🟢🟡🔴 信頼性レベル: [この実装が元資料のどの程度に基づいているか] + * 🔵🟡🔴 信頼性レベル: [この実装が元資料のどの程度に基づいているか] * @param {type} paramName - [パラメータの説明] * @returns {type} - [戻り値の説明] */ @@ -78,13 +85,13 @@ function {{function_name}}(paramName) { ```javascript function processData(input) { - // 【入力値検証】: [入力値の妥当性をチェックする理由と方法] 🟢🟡🔴 + // 【入力値検証】: [入力値の妥当性をチェックする理由と方法] 🔵🟡🔴 if (!input) { - throw new Error('入力値が不正です'); // 【エラー処理】: [なぜこのエラーが必要かを説明] 🟢🟡🔴 + throw new Error('入力値が不正です'); // 【エラー処理】: [なぜこのエラーが必要かを説明] 🔵🟡🔴 } - // 【データ処理開始】: [メイン処理の開始を明示] 🟢🟡🔴 - // 【処理方針】: [この処理がテストを通すためにどう貢献するかを説明] 🟢🟡🔴 + // 【データ処理開始】: [メイン処理の開始を明示] 🔵🟡🔴 + // 【処理方針】: [この処理がテストを通すためにどう貢献するかを説明] 🔵🟡🔴 const result = { // 【結果構造】: [戻り値の構造とその理由を説明] validData: [], @@ -185,10 +192,10 @@ function {{function_name}}(input) { 実装完了後、以下を実行してください： -1. **メモファイル更新**: docs/implements/{{task_id}}/{feature_name}-memo.mdファイルのGreenフェーズセクションを更新 +1. **メモファイル更新**: `docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md` ファイルのGreenフェーズセクションを更新 - 実装方針、実装コード、テスト結果、課題・改善点を記録 - 次のRefactorフェーズで参照できるよう詳細に記録 -2. 実装コードと設計内容をdocs/implements/{{task_id}}/{feature_name}-green-phase.mdに保存（既存ファイルがある場合は追記） +2. 実装コードと設計内容を `docs/implements/{要件名}/{{task_id}}/{feature_name}-green-phase.md` に保存（既存ファイルがある場合は追記） 3. TODOステータスを更新（Greenフェーズ完了をマーク） 4. **自動遷移判定**: 以下の条件を満たす場合は自動で `/tdd-refactor` を実行 - Taskツールを使用して全てのテストが成功していることを確認済み diff --git a/commands/tdd-load-context.md b/commands/tdd-load-context.md index 974cae7..4f65666 100644 --- a/commands/tdd-load-context.md +++ b/commands/tdd-load-context.md @@ -19,15 +19,15 @@ description: TDD関連ファイル読み込み・コンテキスト準備を行 ``` 1. 【読み込み】TDDメモファイルの確認 - - Readツール: `docs/implements/{{task_id}}/{feature_name}-memo.md` + - Readツール: `docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md` - 既存の開発履歴、フェーズ情報、検証結果を把握 2. 【読み込み】要件定義文書の確認 - - Readツール: `docs/implements/{{task_id}}/{feature_name}-requirements.md` + - Readツール: `docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md` - 機能仕様、入出力、制約条件を把握 3. 【読み込み】テストケース定義の確認 - - Readツール: `docs/implements/{{task_id}}/{feature_name}-testcases.md` + - Readツール: `docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md` - 予定テストケース、分類、期待値を把握 4. 【探索のみ】プロジェクト設計文書の特定 @@ -91,7 +91,7 @@ description: TDD関連ファイル読み込み・コンテキスト準備を行 読み込んだ各情報について信頼性レベルを判定： -- 🟢 **青信号**: ファイルが存在し、詳細な情報が利用可能 +- 🔵 **青信号**: ファイルが存在し、詳細な情報が利用可能 - 🟡 **黄信号**: ファイルが存在するが情報が部分的 - 🔴 **赤信号**: ファイルが存在しない、または推測が必要 @@ -117,4 +117,4 @@ description: TDD関連ファイル読み込み・コンテキスト準備を行 - **保守性**: ファイル読み込み・探索ロジックの一元管理 - **軽量化**: 関連ファイルは特定のみで、必要に応じて個別に読み込み可能 -このタスクにより、@agent-symbol-searcherでの検索結果と既存TDDファイルの情報を組み合わせ、TDD開発の各フェーズで必要な情報を効率的に準備できます。 +このタスクにより、@agent-symbol-searcherでの検索結果と既存TDDファイルの情報を組み合わせ、TDD開発の各フェーズで必要な情報を効率的に準備できます。 \ No newline at end of file diff --git a/commands/tdd-red.md b/commands/tdd-red.md index e12d9e7..a8a0367 100644 --- a/commands/tdd-red.md +++ b/commands/tdd-red.md @@ -10,15 +10,29 @@ TDDのRedフェーズを実行します。 開発コンテキストの準備を行います： -1. **@agent-symbol-searcher でテスト実装関連情報を検索し、見つかったファイルを読み込み** +1. **追加ルールの読み込み** + - `AGENTS.md` ファイルが存在する場合は読み込み + - `docs/rule` ディレクトリが存在する場合は読み込み + - `docs/rule/tdd` ディレクトリが存在する場合は読み込み + - `docs/rule/tdd/red` ディレクトリが存在する場合は読み込み + - 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用 + +2. **技術スタック定義の読み込み** + - `docs/tech-stack.md` が存在する場合は読み込み + - 存在しない場合は `CLAUDE.md` から技術スタックセクションを読み込み + - どちらも存在しない場合は `.claude/commands/tech-stack.md` のデフォルト定義を使用 + +3. **@agent-symbol-searcher でテスト実装関連情報を検索し、見つかったファイルを読み込み** + - 読み込んだ技術スタック定義に基づいてテストフレームワークを特定 + - **UIタスクの場合**: E2Eテストフレームワーク（Playwright等）の設定とサンプルを優先的に確認 - 既存のテストファイルやテスト関数を検索し、該当ファイルをReadツールで読み込み - テストセットアップやモックの使用パターンを特定し、関連ファイルをReadツールで読み込み - - Jest/Mochaなどのテストフレームワークの設定を確認し、設定ファイルをReadツールで読み込み + - **E2Eテスト設定確認**: playwright.config.js、cypress.config.js等の設定ファイルをReadツールで読み込み -2. **関連ファイルを直接読み込み** - - `docs/implements/{{task_id}}/{feature_name}-memo.md` - 既存の開発履歴を確認 - - `docs/implements/{{task_id}}/{feature_name}-requirements.md` - 要件定義を確認 - - `docs/implements/{{task_id}}/{feature_name}-testcases.md` - テストケース定義を確認 +4. **関連ファイルを直接読み込み** + - `docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md` - 既存の開発履歴を確認 + - `docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md` - 要件定義を確認 + - `docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md` - テストケース定義を確認 - 関連する設計文書やタスクファイルも必要に応じて読み込み 読み込み完了後、準備されたコンテキスト情報を基にRedフェーズ（失敗テスト作成）の作業を開始します。 @@ -33,26 +47,98 @@ TDDのRedフェーズを実行します。 未実装のテストケースから10個以上のテストケースを選択して実装してください。利用可能なテストケースが10個未満の場合は、利用可能な全てのテストケースを実装対象とします。 既にテストケースが実装済みの場合はテストケース定義に書かれているテストケースからテストを追加します。 +要件網羅率と機能網羅率を高めるテストケースを追加してください +NEVER テストケースの最大行数を500行を目標に分割してください ## 信頼性レベル指示 テストコード作成時には、各テストケースの内容について元の資料との照合状況を以下の信号でコメントしてください： -- 🟢 **青信号**: 元の資料を参考にしてほぼ推測していない場合 +- 🔵 **青信号**: 元の資料を参考にしてほぼ推測していない場合 - 🟡 **黄信号**: 元の資料から妥当な推測の場合 - 🔴 **赤信号**: 元の資料にない推測の場合 ## 要件 -- **使用言語/フレームワーク**: {{language_framework}} +- **使用言語/フレームワーク**: 読み込んだ技術スタック定義に基づく - テストは必ず失敗する状態で作成 - テスト名は分かりやすく日本語で記述 - アサーション（期待値の検証）を明確に記述 - まだ実装されていない関数・メソッドを呼び出す形で作成 +## 🎯 UI開発タスクでの**E2Eテスト優先**方針 + +**UIコンポーネントや画面機能の開発タスクでは、E2Eテスト（特にPlaywright）を最優先で活用してください：** + +### 🚀 E2Eテストを**必須**とすべきケース + +- **ユーザーインターフェースの動作確認** - UIコンポーネントの表示・非表示、状態変更 +- **画面遷移やナビゲーションの検証** - ページ間の移動、ルーティングの動作 +- **フォーム入力と送信機能のテスト** - 入力検証、エラー処理、送信後の動作 +- **ユーザーインタラクション** - クリック、入力、スクロール、ドラッグ＆ドロップ等 +- **ブラウザ固有の動作確認** - 異なるブラウザでの互換性テスト +- **レスポンシブデザインの検証** - 画面サイズによるレイアウト変更 +- **アクセシビリティの確認** - キーボード操作、スクリーンリーダー対応 +- **パフォーマンスの確認** - 読み込み時間、レンダリング速度 + +#### E2Eテストの作成方針 +- **実際のユーザー操作を模倣**: クリック、入力、ナビゲーション等の実際の操作をテストに含める +- **エンドツーエンドのシナリオ**: ログインから目的の操作完了まで、完全なユーザージャーニーをテスト +- **視覚的な検証**: 画面表示、要素の配置、スタイリングの確認を含める +- **複数ブラウザでの検証**: 主要ブラウザでの動作確認を実施 +- **レスポンシブ対応**: 様々な画面サイズでの動作確認 + +### 🥇 **Playwright強力推奨**フレームワーク + +**UIタスクでは原則としてPlaywrightを使用してください：** + +#### 1. **Playwright** (🎯最優先推奨) + - ✅ 複数ブラウザサポート（Chrome, Firefox, Safari） + - ✅ 高速で安定した実行 + - ✅ 豊富なアサーション機能とセレクター + - ✅ 自動待機機能（要素の表示/非表示を自動待機） + - ✅ ネットワーク監視・モック機能 + - ✅ スクリーンショット・動画録画 + - ✅ パフォーマンス測定機能 + - ✅ アクセシビリティテスト統合 + +#### 2. **Cypress** (補完的選択肢) + - 開発者フレンドリーなAPI + - リアルタイムデバッグ機能 + - ※ シングルタブ制限あり + +#### 3. **WebDriver/Selenium** (レガシー対応時のみ) + - 幅広いブラウザサポート + - 成熟したエコシステム + - ※ 設定が複雑、実行速度が遅い + +## 🧭 テスト戦略選択ガイド + +### UI関連タスクの場合 → **E2Eテスト最優先** +- コンポーネント作成・修正 +- ページ作成・レイアウト変更 +- ユーザーインタラクション実装 +- フォーム機能実装 +- ナビゲーション・ルーティング + +### ビジネスロジック・API関連タスク → **単体・統合テスト** +- データ処理アルゴリズム +- バリデーション関数 +- API エンドポイント +- データベース操作 +- ユーティリティ関数 + ## テストコード作成指針 -- Given-When-Then パターンを意識した構造 +### E2Eテスト重視の構造 +- **Scenario-Given-When-Then パターン**を採用 +- **シナリオ定義**: どのようなユーザージャーニーをテストするか +- **初期状態設定（Given）**: ページアクセス、ログイン状態等 +- **ユーザー操作実行（When）**: クリック、入力、ナビゲーション等 +- **結果確認（Then）**: 画面表示、状態変化、ページ遷移等 + +### 単体・統合テスト用の構造 +- **Given-When-Then パターン**を使用 - テストデータの準備（Given） - 実際の処理の実行（When） - 結果の検証（Then） @@ -69,7 +155,7 @@ describe('{{feature_name}}', () => { // 【テスト目的】: [このテストで何を確認するかを日本語で明記] // 【テスト内容】: [具体的にどのような処理をテストするかを説明] // 【期待される動作】: [正常に動作した場合の結果を説明] - // 🟢🟡🔴 信頼性レベル: [このテストの内容が元資料のどの程度に基づいているか] + // 🔵🟡🔴 信頼性レベル: [このテストの内容が元資料のどの程度に基づいているか] // 【テストデータ準備】: [なぜこのデータを用意するかの理由] // 【初期条件設定】: [テスト実行前の状態を説明] @@ -81,7 +167,7 @@ describe('{{feature_name}}', () => { // 【結果検証】: [何を検証するかを具体的に説明] // 【期待値確認】: [期待される結果とその理由を説明] - expect(result).toBe({{expected_output}}); // 【確認内容】: [この検証で確認している具体的な項目] 🟢🟡🔴 + expect(result).toBe({{expected_output}}); // 【確認内容】: [この検証で確認している具体的な項目] 🔵🟡🔴 }); }); ``` @@ -112,6 +198,8 @@ expect(result.errors).toContain('error message'); // 【確認内容】: [特定 ## 作成するテストコードの例 +### 単体テスト・統合テストの例 + ```javascript // テストファイル: {{test_file_name}} describe('{{feature_name}}', () => { @@ -129,7 +217,7 @@ describe('{{feature_name}}', () => { // 【テスト目的】: {{test_purpose}} // 【テスト内容】: {{test_description}} // 【期待される動作】: {{expected_behavior}} - // 🟢🟡🔴 信頼性レベル: [このテストの内容が元資料のどの程度に基づいているか] + // 🔵🟡🔴 信頼性レベル: [このテストの内容が元資料のどの程度に基づいているか] // 【テストデータ準備】: {{test_data_reason}} // 【初期条件設定】: {{initial_condition}} @@ -146,6 +234,102 @@ describe('{{feature_name}}', () => { }); ``` +### UIタスク向けE2Eテストの例（Playwright） + +```javascript +// E2Eテストファイル: tests/e2e/{{feature_name}}.spec.js +import { test, expect } from '@playwright/test'; + +describe('{{feature_name}} E2Eテスト', () => { + test.beforeEach(async ({ page }) => { + // 【E2Eテスト前準備】: ブラウザを起動し、テスト対象のページに移動 + // 【環境初期化】: 各テストを独立して実行するため、ページ状態をリセット + await page.goto('/{{target_page}}'); + }); + + test('{{ui_test_case_name}}', async ({ page }) => { + // 【テスト目的】: {{ui_test_purpose}} + // 【テスト内容】: {{ui_test_description}} + // 【期待される動作】: {{expected_ui_behavior}} + // 🔵🟡🔴 信頼性レベル: [このテストの内容が元資料のどの程度に基づいているか] + + // 【初期状態確認】: {{initial_ui_state_reason}} + // 【画面表示確認】: {{screen_display_verification}} + await expect(page.locator('{{initial_element_selector}}')).toBeVisible(); + // 【確認内容】: 初期状態で必要な要素が表示されていることを確認 + + // 【ユーザー操作実行】: {{user_action_description}} + // 【操作内容】: {{specific_action_description}} + await page.click('{{target_button_selector}}'); + await page.fill('{{input_selector}}', '{{test_input_value}}'); + await page.click('{{submit_button_selector}}'); + + // 【結果確認】: {{ui_result_verification}} + // 【期待される表示変化】: {{expected_ui_changes}} + await expect(page.locator('{{result_element_selector}}')).toContainText('{{expected_text}}'); + // 【確認内容】: {{specific_ui_verification_point}} + + // 【追加検証】: {{additional_verification_description}} + await expect(page).toHaveURL('{{expected_url}}'); + // 【確認内容】: 正しいページに遷移したことを確認 + }); + + test('{{responsive_test_case_name}}', async ({ page }) => { + // 【テスト目的】: レスポンシブデザインの動作確認 + // 【テスト内容】: 異なる画面サイズでのUI表示とユーザビリティの検証 + // 【期待される動作】: モバイル・タブレット・デスクトップサイズで適切に表示される + // 🔵🟡🔴 信頼性レベル: [このテストの内容が元資料のどの程度に基づいているか] + + // 【画面サイズ設定】: モバイルサイズでの表示確認 + // 【レスポンシブ確認】: 小さい画面での要素配置とユーザビリティをテスト + await page.setViewportSize({ width: 375, height: 667 }); + + // 【モバイル表示確認】: モバイル向けレイアウトが適用されることを確認 + await expect(page.locator('{{mobile_navigation_selector}}')).toBeVisible(); + // 【確認内容】: モバイル用ナビゲーションが表示されている + + // 【タブレットサイズ設定】: 中間サイズでの表示確認 + await page.setViewportSize({ width: 768, height: 1024 }); + + // 【タブレット表示確認】: タブレット向けレイアウトの動作を確認 + await expect(page.locator('{{tablet_layout_selector}}')).toBeVisible(); + // 【確認内容】: タブレット用レイアウトが適切に表示されている + }); +}); +``` + +### アクセシビリティテストの例 + +```javascript +// アクセシビリティテストファイル: tests/e2e/accessibility/{{feature_name}}.spec.js +import { test, expect } from '@playwright/test'; +import AxeBuilder from '@axe-core/playwright'; + +describe('{{feature_name}} アクセシビリティテスト', () => { + test('{{accessibility_test_case_name}}', async ({ page }) => { + // 【テスト目的】: Webアクセシビリティガイドライン（WCAG）準拠の確認 + // 【テスト内容】: 自動アクセシビリティ検査とキーボード操作の検証 + // 【期待される動作】: アクセシビリティ違反がなく、キーボードで操作可能 + // 🔵🟡🔴 信頼性レベル: [このテストの内容が元資料のどの程度に基づいているか] + + // 【ページ読み込み】: テスト対象ページへの移動 + await page.goto('/{{target_page}}'); + + // 【自動アクセシビリティ検査】: axe-coreを使用した自動検査 + // 【WCAG準拠確認】: 色のコントラスト、ALTテキスト、ラベル等の確認 + const accessibilityScanResults = await new AxeBuilder({ page }).analyze(); + expect(accessibilityScanResults.violations).toEqual([]); + // 【確認内容】: アクセシビリティ違反が検出されないことを確認 + + // 【キーボード操作確認】: Tabキーによるフォーカス移動の検証 + // 【操作性確認】: マウスを使わずにすべての機能が利用可能であることを確認 + await page.keyboard.press('Tab'); + await expect(page.locator('{{first_focusable_element}}')).toBeFocused(); + // 【確認内容】: 最初のフォーカス可能要素にフォーカスが移動している + }); +}); +``` + ## 提供してください 1. **テストコード**: 実行可能な形式で、必須の日本語コメント付き @@ -153,12 +337,52 @@ describe('{{feature_name}}', () => { 3. **期待される失敗メッセージ**: どのようなエラーが出るか 4. **コメントの説明**: 各日本語コメントの意図と目的 +### E2Eテスト実行コマンドの例 + +#### Playwrightの場合 +```bash +# 全E2Eテスト実行 +npx playwright test + +# 特定のテストファイル実行 +npx playwright test tests/e2e/{{feature_name}}.spec.js + +# ヘッドレスモードでない実行（ブラウザ表示） +npx playwright test --headed + +# 特定のブラウザでのテスト実行 +npx playwright test --project=chromium +npx playwright test --project=firefox +npx playwright test --project=webkit + +# デバッグモードでの実行 +npx playwright test --debug + +# レポート生成 +npx playwright show-report +``` + +#### Cypressの場合 +```bash +# Cypress Test Runnerを開く +npx cypress open + +# ヘッドレスモードでテスト実行 +npx cypress run + +# 特定のテストファイル実行 +npx cypress run --spec "cypress/e2e/{{feature_name}}.cy.js" + +# 特定のブラウザでの実行 +npx cypress run --browser chrome +``` + テストコード作成後、以下を実行してください： -1. **メモファイル作成・更新**: docs/implements/{{task_id}}/{feature_name}-memo.mdファイルにRedフェーズの内容を作成または追記 +1. **メモファイル作成・更新**: `docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md` ファイルにRedフェーズの内容を作成または追記 - 既存のメモファイルがある場合は、Redフェーズセクションを更新 - メモファイルが存在しない場合は新規作成 -2. テストコードの設計内容をdocs/implements/{{task_id}}/{feature_name}-red-phase.mdに保存（既存ファイルがある場合は追記） +2. テストコードの設計内容を `docs/implements/{要件名}/{{task_id}}/{feature_name}-red-phase.md` に保存（既存ファイルがある場合は追記） 3. TODOステータスを更新（Redフェーズ完了をマーク） 4. **品質判定**: テストコードの品質を以下の基準で判定 - テスト実行: 実行可能で失敗することを確認済み @@ -170,7 +394,7 @@ describe('{{feature_name}}', () => { ## TDDメモファイル形式 -docs/implements/{{task_id}}/{feature_name}-memo.mdファイルの形式： +`docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md` ファイルの形式： ```markdown # TDD開発メモ: {feature_name} @@ -184,8 +408,8 @@ docs/implements/{{task_id}}/{feature_name}-memo.mdファイルの形式： ## 関連ファイル - 元タスクファイル: `docs/tasks/{taskファイルのパス}.md` -- 要件定義: `docs/implements/{{task_id}}/{feature_name}-requirements.md` -- テストケース定義: `docs/implements/{{task_id}}/{feature_name}-testcases.md` +- 要件定義: `docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md` +- テストケース定義: `docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md` - 実装ファイル: `[実装ファイルのパス]` - テストファイル: `[テストファイルのパス]` diff --git a/commands/tdd-refactor.md b/commands/tdd-refactor.md index 2dddf03..bf9f74b 100644 --- a/commands/tdd-refactor.md +++ b/commands/tdd-refactor.md @@ -10,16 +10,23 @@ TDDのRefactorフェーズを実行します。 開発コンテキストの準備を行います： -1. **@agent-symbol-searcher でリファクタリング関連情報を検索し、見つかったファイルを読み込み** +1. **追加ルールの読み込み** + - `AGENTS.md` ファイルが存在する場合は読み込み + - `docs/rule` ディレクトリが存在する場合は読み込み + - `docs/rule/tdd` ディレクトリが存在する場合は読み込み + - `docs/rule/tdd/refactor` ディレクトリが存在する場合は読み込み + - 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用 + +2. **@agent-symbol-searcher でリファクタリング関連情報を検索し、見つかったファイルを読み込み** - 既存のコードスタイルやベストプラクティスを検索し、スタイルガイドをReadツールで読み込み - プロジェクト全体のアーキテクチャパターンを特定し、設計文書をReadツールで読み込み - 再利用可能なユーティリティ関数やコンポーネントを確認し、関連ファイルをReadツールで読み込み -2. **関連ファイルを直接読み込み** - - `docs/implements/{{task_id}}/{feature_name}-memo.md` - 既存の開発履歴を確認 - - `docs/implements/{{task_id}}/{feature_name}-requirements.md` - 要件定義を確認 - - `docs/implements/{{task_id}}/{feature_name}-testcases.md` - テストケース定義を確認 - - `docs/implements/{{task_id}}/{feature_name}-green-phase.md` - Greenフェーズの実装を確認 +3. **関連ファイルを直接読み込み** + - `docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md` - 既存の開発履歴を確認 + - `docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md` - 要件定義を確認 + - `docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md` - テストケース定義を確認 + - `docs/implements/{要件名}/{{task_id}}/{feature_name}-green-phase.md` - Greenフェーズの実装を確認 - 関連する設計文書やタスクファイルも必要に応じて読み込み 読み込み完了後、準備されたコンテキスト情報を基にRefactorフェーズ（コード改善）の作業を開始します。 @@ -28,7 +35,7 @@ TDDのRefactorフェーズを実行します。 リファクタリング時には、各改善内容について元の資料との照合状況を以下の信号でコメントしてください： -- 🟢 **青信号**: 元の資料を参考にしてほぼ推測していない場合 +- 🔵 **青信号**: 元の資料を参考にしてほぼ推測していない場合 - 🟡 **黄信号**: 元の資料から妥当な推測の場合 - 🔴 **赤信号**: 元の資料にない推測の場合 @@ -111,7 +118,7 @@ Greenフェーズで実装されたコードを以下の観点で改善してく * 【設計方針】: [なぜこの設計にしたかの理由] * 【パフォーマンス】: [性能面での考慮事項] * 【保守性】: [メンテナンスしやすくするための工夫] - * 🟢🟡🔴 信頼性レベル: [この改善が元資料のどの程度に基づいているか] + * 🔵🟡🔴 信頼性レベル: [この改善が元資料のどの程度に基づいているか] * @param {type} paramName - [パラメータの詳細説明と制約] * @returns {type} - [戻り値の詳細説明と保証事項] */ @@ -129,17 +136,17 @@ function improvedFunction(paramName) { * 【単一責任】: [この関数が担当する責任の範囲] */ function helperFunction(input) { - // 【処理効率化】: [処理を効率化するための工夫] 🟢🟡🔴 - // 【可読性向上】: [コードの読みやすさを向上させる仕組み] 🟢🟡🔴 + // 【処理効率化】: [処理を効率化するための工夫] 🔵🟡🔴 + // 【可読性向上】: [コードの読みやすさを向上させる仕組み] 🔵🟡🔴 } ``` ### 定数・設定値のコメント ```javascript -// 【設定定数】: [この定数の役割と設定理由] 🟢🟡🔴 -// 【調整可能性】: [将来的に調整が必要になる可能性と方法] 🟢🟡🔴 -const IMPROVED_CONSTANT = 100; // 【最適化済み】: パフォーマンステストに基づき最適化 🟢🟡🔴 +// 【設定定数】: [この定数の役割と設定理由] 🔵🟡🔴 +// 【調整可能性】: [将来的に調整が必要になる可能性と方法] 🔵🟡🔴 +const IMPROVED_CONSTANT = 100; // 【最適化済み】: パフォーマンステストに基づき最適化 🔵🟡🔴 // 【設定オブジェクト】: [設定をまとめた理由と管理方針] const CONFIG = { @@ -262,11 +269,11 @@ function add(firstNumber, secondNumber) { リファクタリング完了後、以下を実行してください： -1. **メモファイル最終更新**: docs/implements/{{task_id}}/{feature_name}-memo.mdファイルのRefactorフェーズセクションと概要を更新 +1. **メモファイル最終更新**: `docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md` ファイルのRefactorフェーズセクションと概要を更新 - 改善内容、セキュリティレビュー結果、パフォーマンスレビュー結果を記録 - 最終コード、品質評価を記録 - 概要セクションの現在のフェーズを「完了」に更新 -2. リファクタリング内容と設計改善をdocs/implements/{{task_id}}/{feature_name}-refactor-phase.mdに保存（既存ファイルがある場合は追記） +2. リファクタリング内容と設計改善を `docs/implements/{要件名}/{{task_id}}/{feature_name}-refactor-phase.md` に保存（既存ファイルがある場合は追記） 3. TODOステータスを更新（Refactorフェーズ完了をマーク） 4. **品質判定**: リファクタリング成果の品質を以下の基準で判定 - テスト結果: 全てのテストが引き続き成功 diff --git a/commands/tdd-requirements.md b/commands/tdd-requirements.md index d28f023..83b0c28 100644 --- a/commands/tdd-requirements.md +++ b/commands/tdd-requirements.md @@ -1,6 +1,7 @@ --- description: TDD開発の要件整理を行います。機能要件を明確化し、テスト駆動開発のための準備を行います。 --- +あなたは開発の要件整理担当者です。TASKから必要な情報を集めて必要な機能を網羅的に整理してください。 # TDD要件定義・機能仕様の整理 @@ -12,15 +13,27 @@ TDD開発を始めます。以下の機能について要件を整理してく 開発コンテキストの準備を行います： -1. **@agent-symbol-searcher で機能関連情報を検索し、見つかったファイルを読み込み** +1. **追加ルールの読み込み** + - `docs/rule` ディレクトリが存在する場合は読み込み + - `docs/rule/tdd` ディレクトリが存在する場合は読み込み + - `docs/rule/tdd/requirements` ディレクトリが存在する場合は読み込み + - 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用 + +2. **技術スタック定義の読み込み** + - `docs/tech-stack.md` が存在する場合は読み込み + - 存在しない場合は `CLAUDE.md` から技術スタックセクションを読み込み + - どちらも存在しない場合は `.claude/commands/tech-stack.md` のデフォルト定義を使用 + +3. **@agent-symbol-searcher で機能関連情報を検索し、見つかったファイルを読み込み** + - 読み込んだ技術スタック定義に基づいて関連ファイルを検索 - 関連する既存機能・コンポーネントを検索し、該当ファイルをReadツールで読み込み - 類似した実装パターンやアーキテクチャを特定し、設計文書をReadツールで読み込み - 既存のインターフェースやAPI仕様を確認し、関連ファイルをReadツールで読み込み -2. **関連ファイルを直接読み込み** - - `docs/implements/{{task_id}}/{feature_name}-memo.md` - 既存の開発履歴を確認 - - `docs/implements/{{task_id}}/{feature_name}-requirements.md` - 既存の要件定義を確認 - - `docs/implements/{{task_id}}/{feature_name}-testcases.md` - 既存のテストケースを確認 +4. **関連ファイルを直接読み込み** + - `docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md` - 既存の開発履歴を確認 + - `docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md` - 既存の要件定義を確認 + - `docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md` - 既存のテストケースを確認 - 関連する設計文書やタスクファイルも必要に応じて読み込み 読み込み完了後、準備されたコンテキスト情報を基にTDD要件定義の作業を開始します。 @@ -30,13 +43,13 @@ TDD開発を始めます。以下の機能について要件を整理してく **【信頼性レベル指示】**: 各項目について、元の資料（EARS要件定義書・設計文書含む）との照合状況を以下の信号でコメントしてください： -- 🟢 **青信号**: EARS要件定義書・設計文書を参考にしてほぼ推測していない場合 +- 🔵 **青信号**: EARS要件定義書・設計文書を参考にしてほぼ推測していない場合 - 🟡 **黄信号**: EARS要件定義書・設計文書から妥当な推測の場合 - 🔴 **赤信号**: EARS要件定義書・設計文書にない推測の場合 ## 1. 機能の概要（EARS要件定義書・設計文書ベース） -- 🟢🟡🔴 各項目の信頼性レベルを記載 +- 🔵🟡🔴 各項目の信頼性レベルを記載 - 何をする機能か（ユーザストーリーから抽出） - どのような問題を解決するか（As a / So that から抽出） - 想定されるユーザー（As a から抽出） @@ -46,7 +59,7 @@ TDD開発を始めます。以下の機能について要件を整理してく ## 2. 入力・出力の仕様（EARS機能要件・TypeScript型定義ベース） -- 🟢🟡🔴 各項目の信頼性レベルを記載 +- 🔵🟡🔴 各項目の信頼性レベルを記載 - 入力パラメータ（型、範囲、制約）- interfaces.tsから抽出 - 出力値（型、形式、例）- interfaces.tsから抽出 - 入出力の関係性 @@ -56,7 +69,7 @@ TDD開発を始めます。以下の機能について要件を整理してく ## 3. 制約条件（EARS非機能要件・アーキテクチャ設計ベース） -- 🟢🟡🔴 各項目の信頼性レベルを記載 +- 🔵🟡🔴 各項目の信頼性レベルを記載 - パフォーマンス要件（NFR-XXXから抽出） - セキュリティ要件（NFR-XXXから抽出） - 互換性要件（REQ-XXX MUSTから抽出） @@ -68,7 +81,7 @@ TDD開発を始めます。以下の機能について要件を整理してく ## 4. 想定される使用例（EARSEdgeケース・データフローベース） -- 🟢🟡🔴 各項目の信頼性レベルを記載 +- 🔵🟡🔴 各項目の信頼性レベルを記載 - 基本的な使用パターン（通常要件REQ-XXXから抽出） - データフロー（dataflow.mdから抽出） - エッジケース（EDGE-XXXから抽出） @@ -94,7 +107,7 @@ TDD開発を始めます。以下の機能について要件を整理してく 整理後、以下を実行してください： -1. 要件定義書をdocs/implements/{{task_id}}/{feature_name}-requirements.mdに保存（既存ファイルがある場合は追記） +1. 要件定義書を `docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md` に保存（既存ファイルがある場合は追記） 2. TODOステータスを更新（要件定義完了をマーク） 3. **品質判定**: 要件の品質を以下の基準で判定 - 要件が明確で曖昧さがない diff --git a/commands/tdd-testcases.md b/commands/tdd-testcases.md index 13c9ad6..8d6042f 100644 --- a/commands/tdd-testcases.md +++ b/commands/tdd-testcases.md @@ -1,24 +1,31 @@ --- description: TDD開発のためのテストケース洗い出しを行います。整理された要件に基づいて包括的なテストケースを特定します。 --- +あなたはテスト設計の担当者です。指定されたtask_idの要件を確認して。網羅的なテストケースを作成してください。 # TDDテストケースの洗い出し -先ほど整理した要件に基づいて、テストケースを洗い出します。 +先ほど整理した要件に基づいて、要件網羅率と機能網羅率が十分に高いテストケースを洗い出します。 ## 事前準備 開発コンテキストの準備を行います： -1. **@agent-symbol-searcher でテスト関連情報を検索し、見つかったファイルを読み込み** +1. **追加ルールの読み込み** + - `docs/rule` ディレクトリが存在する場合は読み込み + - `docs/rule/tdd` ディレクトリが存在する場合は読み込み + - `docs/rule/tdd/testcases` ディレクトリが存在する場合は読み込み + - 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用 + +2. **@agent-symbol-searcher でテスト関連情報を検索し、見つかったファイルを読み込み** - 既存のテストパターンやテストケースを検索し、該当テストファイルをReadツールで読み込み - 類似機能のテスト方法やモック戦略を特定し、関連ファイルをReadツールで読み込み - テストフレームワークの使用方法を確認し、設定ファイルをReadツールで読み込み -2. **関連ファイルを直接読み込み** - - `docs/implements/{{task_id}}/{feature_name}-memo.md` - 既存の開発履歴を確認 - - `docs/implements/{{task_id}}/{feature_name}-requirements.md` - 要件定義を確認 - - `docs/implements/{{task_id}}/{feature_name}-testcases.md` - 既存のテストケースを確認 +3. **関連ファイルを直接読み込み** + - `docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md` - 既存の開発履歴を確認 + - `docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md` - 要件定義を確認 + - `docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md` - 既存のテストケースを確認 - 関連する設計文書やタスクファイルも必要に応じて読み込み 読み込み完了後、準備されたコンテキスト情報を基にテストケースの洗い出しを行います。 @@ -27,7 +34,7 @@ description: TDD開発のためのテストケース洗い出しを行います 各テストケースの作成時には、元の資料（要件定義、既存実装、ライブラリドキュメント等）との照合状況を以下の信号で必ずコメントしてください： -- 🟢 **青信号**: 元の資料を参考にしてほぼ推測していない場合 +- 🔵 **青信号**: 元の資料を参考にしてほぼ推測していない場合 - 🟡 **黄信号**: 元の資料から妥当な推測の場合 - 🔴 **赤信号**: 元の資料にない推測の場合 @@ -46,7 +53,7 @@ description: TDD開発のためのテストケース洗い出しを行います - **期待結果の理由**: [なぜこの結果が正しいとされるか] - **テストの目的**: [何を確認するか] - **確認ポイント**: [特に注意して検証すべき点] -- 🟢🟡🔴 このテストケースの信頼性レベルを記載 +- 🔵🟡🔴 このテストケースの信頼性レベルを記載 ### 2. 異常系テストケース（エラーハンドリング） @@ -61,7 +68,7 @@ description: TDD開発のためのテストケース洗い出しを行います - **システムの安全性**: [エラー時にシステムが安全な状態を保てるか] - **テストの目的**: [エラーハンドリングの確認] - **品質保証の観点**: [このテストがシステム品質にどう貢献するか] -- 🟢🟡🔴 このテストケースの信頼性レベルを記載 +- 🔵🟡🔴 このテストケースの信頼性レベルを記載 ### 3. 境界値テストケース（最小値、最大値、null等） @@ -76,7 +83,7 @@ description: TDD開発のためのテストケース洗い出しを行います - **一貫した動作**: [境界の内側と外側で動作が一貫しているか] - **テストの目的**: [境界条件の確認] - **堅牢性の確認**: [システムが極端な条件下でも安定動作するか] -- 🟢🟡🔴 このテストケースの信頼性レベルを記載 +- 🔵🟡🔴 このテストケースの信頼性レベルを記載 ## 開発言語・フレームワーク @@ -88,7 +95,7 @@ description: TDD開発のためのテストケース洗い出しを行います - **テストフレームワーク**: {{test_framework}} - **フレームワーク選択の理由**: [なぜこのテストフレームワークを選んだか] - **テスト実行環境**: [どのような環境でテストを実行するか] -- 🟢🟡🔴 この内容の信頼性レベルを記載 +- 🔵🟡🔴 この内容の信頼性レベルを記載 ## テストケース実装時の日本語コメント指針 @@ -100,7 +107,7 @@ description: TDD開発のためのテストケース洗い出しを行います // 【テスト目的】: [このテストで何を確認するかを日本語で明記] // 【テスト内容】: [具体的にどのような処理をテストするかを説明] // 【期待される動作】: [正常に動作した場合の結果を説明] -// 🟢🟡🔴 この内容の信頼性レベルを記載 +// 🔵🟡🔴 この内容の信頼性レベルを記載 ``` ### Given（準備フェーズ）のコメント @@ -131,7 +138,7 @@ description: TDD開発のためのテストケース洗い出しを行います ```javascript // 【検証項目】: [この検証で確認している具体的な項目] -// 🟢🟡🔴 この内容の信頼性レベルを記載 +// 🔵🟡🔴 この内容の信頼性レベルを記載 expect(result.validPaths).toHaveLength(2); // 【確認内容】: 有効なパスが正確に2つ検出されることを確認 expect(result.invalidPaths).toContain('nonexistent.json'); // 【確認内容】: 存在しないファイルが無効パスとして適切に分類されることを確認 ``` @@ -152,7 +159,7 @@ afterEach(() => { すべて洗い出したら以下を実行してください： -1. テストケース一覧をdocs/implements/{{task_id}}/{feature_name}-testcases.mdに保存（既存ファイルがある場合は追記） +1. テストケース一覧を `docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md` に保存（既存ファイルがある場合は追記） 2. TODOステータスを更新（テストケース洗い出し完了をマーク） 3. **品質判定**: テストケースの品質を以下の基準で判定 - テストケース分類: 正常系・異常系・境界値が網羅されている diff --git a/commands/tdd-todo.md b/commands/tdd-todo.md index c57bba7..0e5e935 100644 --- a/commands/tdd-todo.md +++ b/commands/tdd-todo.md @@ -7,7 +7,7 @@ description: タスクファイルから実装可能なTODOリストを作成し ## 入力 - `docs/tasks/{要件名}-tasks.md` ファイル -- 各タスクのタスクID（TASK-001, TASK-101など） +- 各タスクのタスクID（{{task_id}}など） - 要件定義文書： - `docs/spec/{要件名}-requirements.md` - 設計文書群： @@ -19,14 +19,20 @@ description: タスクファイルから実装可能なTODOリストを作成し ## 作成手順 -1. **要件定義文書の分析** +1. **追加ルールの読み込み** + - `docs/rule` ディレクトリが存在する場合は読み込み + - `docs/rule/tdd` ディレクトリが存在する場合は読み込み + - `docs/rule/tdd/todo` ディレクトリが存在する場合は読み込み + - 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用 + +2. **要件定義文書の分析** - @agent-symbol-searcher で関連要件・設計文書を検索 - EARS記法による要件の理解 - ユーザストーリーと価値の把握 - 機能要件と非機能要件の確認 - Edgeケースと受け入れ基準の理解 -2. **設計文書の分析** +3. **設計文書の分析** - @agent-symbol-searcher で既存アーキテクチャパターンを検索 - アーキテクチャ設計の全体像を把握 - データベーススキーマの構造を理解 @@ -34,14 +40,14 @@ description: タスクファイルから実装可能なTODOリストを作成し - インターフェース定義を分析 - データフローの設計を理解 -3. **タスクファイルの分析** +4. **タスクファイルの分析** - @agent-symbol-searcher で関連タスクIDや完了状態を検索 - 全体のフェーズ構造を把握 - タスクID別の実装内容を確認 - 依存関係と実行順序を理解 - 要件定義と設計文書との整合性を確認 -4. **TODO作成時の注意点** +5. **TODO作成時の注意点** - タスクIDを保持してトレーサビリティを確保 - 依存関係を考慮した順序付け - 各タスクの完了条件を明確化 @@ -56,7 +62,7 @@ description: タスクファイルから実装可能なTODOリストを作成し - **DIRECT**: 設定作業のみ（環境構築、設定ファイル、依存関係など） - **TDD**: 仕様に合わせた実装を伴う作業（ビジネスロジック、API実装、UI実装など） -5. **出力形式** +6. **出力形式** ```markdown # {要件名} 実装TODO @@ -73,14 +79,14 @@ description: タスクファイルから実装可能なTODOリストを作成し ### フェーズ1: 基盤構築 -- [ ] **TASK-001 [DIRECT]**: {タスク名} (REQ-{XXX}対応) +- [ ] **{{task_id}} [DIRECT]**: {{タスク名}} (REQ-{{XXX}}対応) - [ ] {実装詳細1（architecture.mdから抽出）} - [ ] {データベース設定（database-schema.sqlから抽出）} - [ ] {テスト要件1} - [ ] {受け入れ基準（requirements.mdから抽出）} - [ ] {完了条件1} -- [ ] **TASK-002 [DIRECT]**: {タスク名} (REQ-{XXX}対応) +- [ ] **{{task_id}} [DIRECT]**: {{タスク名}} (REQ-{{XXX}}対応) - [ ] {実装詳細1（architecture.mdから抽出）} - [ ] {環境設定（dataflow.mdから抽出）} - [ ] {テスト要件1} @@ -89,7 +95,7 @@ description: タスクファイルから実装可能なTODOリストを作成し ### フェーズ2: API実装 -- [ ] **TASK-101 [TDD]**: {タスク名} (REQ-{XXX}対応) +- [ ] **{{task_id}} [TDD]**: {{タスク名}} (REQ-{{XXX}}対応) - [ ] {実装詳細1（api-endpoints.mdから抽出）} - [ ] {インターフェース実装（interfaces.tsから抽出）} - [ ] {テスト要件1} @@ -98,7 +104,7 @@ description: タスクファイルから実装可能なTODOリストを作成し ### フェーズ3: フロントエンド実装 -- [ ] **TASK-201 [TDD]**: {タスク名} (REQ-{XXX}対応) +- [ ] **{{task_id}} [TDD]**: {{タスク名}} (REQ-{{XXX}}対応) - [ ] {実装詳細1（interfaces.tsから抽出）} - [ ] {データフロー実装（dataflow.mdから抽出）} - [ ] {UI/UX要件1} @@ -108,7 +114,7 @@ description: タスクファイルから実装可能なTODOリストを作成し ### フェーズ4: 統合・最適化 -- [ ] **TASK-301 [TDD]**: {タスク名} (REQ-{XXX}対応) +- [ ] **{{task_id}} [TDD]**: {{タスク名}} (REQ-{{XXX}}対応) - [ ] {実装詳細1（全設計文書から抽出）} - [ ] {E2Eテスト（dataflow.mdから抽出）} - [ ] {パフォーマンス要件（NFR-001から抽出）} diff --git a/commands/tdd-verify-complete.md b/commands/tdd-verify-complete.md index 33ce8ac..d3401df 100644 --- a/commands/tdd-verify-complete.md +++ b/commands/tdd-verify-complete.md @@ -17,6 +17,8 @@ TDD開発でテストケースの実装が完全に完了しているかを検 - 問題を発見した場合は内容をmemoファイルに記載する - 修正作業は後の工程（次のTDDサイクルや別のタスク）に委ねる - 検証・記録・報告に専念する +- テストの実行は @task で実行する +- NEVER 全体のテストケースの実装率と成功率のレポートは省略しない ## 検証手順 @@ -32,16 +34,23 @@ TDD開発でテストケースの実装が完全に完了しているかを検 検証コンテキストの準備を行います： -1. **@agent-symbol-searcher で検証関連情報を検索し、見つかったファイルを読み込み** +1. **追加ルールの読み込み** + - `AGENTS.md` ファイルが存在する場合は読み込み + - `docs/rule` ディレクトリが存在する場合は読み込み + - `docs/rule/tdd` ディレクトリが存在する場合は読み込み + - `docs/rule/tdd/verify-complete` ディレクトリが存在する場合は読み込み + - 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用 + +2. **@agent-symbol-searcher で検証関連情報を検索し、見つかったファイルを読み込み** - 完了予定のテストケースや機能を検索し、該当ファイルをReadツールで読み込み - 既存のテストカバレッジや品質基準を確認し、関連ファイルをReadツールで読み込み - 実装完了タスクのマーキングパターンを特定し、タスクファイルをReadツールで読み込み -2. **関連ファイルを直接読み込み** - - `docs/implements/{{task_id}}/{feature_name}-memo.md` - 既存の開発履歴を確認 - - `docs/implements/{{task_id}}/{feature_name}-requirements.md` - 要件定義を確認 - - `docs/implements/{{task_id}}/{feature_name}-testcases.md` - テストケース定義を確認 - - `docs/implements/{{task_id}}/{feature_name}-refactor-phase.md` - Refactorフェーズの結果を確認 +3. **関連ファイルを直接読み込み** + - `docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md` - 既存の開発履歴を確認 + - `docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md` - 要件定義を確認 + - `docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md` - テストケース定義を確認 + - `docs/implements/{要件名}/{{task_id}}/{feature_name}-refactor-phase.md` - Refactorフェーズの結果を確認 - 元タスクファイル (`docs/tasks/{taskfile}.md`) - タスクの完了状態を確認 読み込み完了後、準備されたコンテキスト情報を基にテストケース完全性検証を開始します。 @@ -133,7 +142,7 @@ TDD開発でテストケースの実装が完全に完了しているかを検 #### メモファイルの統合更新 -検証完了後、`docs/implements/{{task_id}}/{feature_name}-memo.md` の既存内容を整理・統合し、以下の情報に更新： +検証完了後、`docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md` の既存内容を整理・統合し、以下の情報に更新： ```markdown # [機能名] TDD開発完了記録 @@ -141,8 +150,8 @@ TDD開発でテストケースの実装が完全に完了しているかを検 ## 確認すべきドキュメント - `docs/tasks/{taskファイルのパス}.md` -- `docs/implements/{{task_id}}/{feature_name}-requirements.md` -- `docs/implements/{{task_id}}/{feature_name}-testcases.md` +- `docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md` +- `docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md` ## 🎯 最終結果 ([日時]) - **実装率**: [数]% ([実装数]/[予定数]テストケース) @@ -253,8 +262,8 @@ TDD開発でテストケースの実装が完全に完了しているかを検 ### 確認すべきドキュメント - **元タスクファイル**: `docs/tasks/{taskファイルのパス}.md` - プロジェクト全体のタスク完了状況（完了マーク更新対象） -- `docs/implements/{{task_id}}/{feature_name}-requirements.md` -- `docs/implements/{{task_id}}/{feature_name}-testcases.md` +- `docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md` +- `docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md` ### 確認すべきテストファイル diff --git a/commands/tech-stack.md b/commands/tech-stack.md new file mode 100644 index 0000000..31be2cc --- /dev/null +++ b/commands/tech-stack.md @@ -0,0 +1,105 @@ +# デフォルト技術スタック定義 + +プロジェクト専用の技術スタック定義ファイルが見つからない場合に使用されるデフォルト定義です。 + +## 優先順位 + +1. **プロジェクト専用**: `docs/tech-stack.md` +2. **プロジェクト共通**: `CLAUDE.md` の技術スタックセクション +3. **デフォルト**: この定義ファイル + +## デフォルト技術スタック + +### フロントエンド +- **フレームワーク**: React 18+ または Vue 3+ または Next.js +- **言語**: TypeScript 5.0+ +- **状態管理**: Redux Toolkit または Zustand または Pinia +- **UIライブラリ**: Material-UI または Tailwind CSS または shadcn/ui +- **バンドラー**: Vite または Webpack + +### バックエンド +- **フレームワーク**: Express.js または Fastify または Next.js API Routes +- **言語**: TypeScript 5.0+ または JavaScript ES2022+ +- **データベース**: PostgreSQL 15+ または MySQL 8+ または SQLite +- **ORM**: Prisma または TypeORM または Drizzle +- **認証**: JWT または NextAuth.js + +### キャッシュ・セッション +- **キャッシュ**: Redis 7+ または Memcached +- **セッション**: Redis または MemoryStore + +### 開発環境 +- **コンテナ**: Docker + Docker Compose +- **パッケージマネージャー**: npm または yarn または pnpm +- **Node.js**: 18+ LTS + +### 開発ツール +- **テストフレームワーク**: Jest または Vitest +- **テストライブラリ**: Testing Library または Playwright +- **リンター**: ESLint + Prettier +- **型チェック**: TypeScript +- **CI/CD**: GitHub Actions または GitLab CI + +### デプロイ・インフラ +- **フロントエンド**: Vercel または Netlify または Cloudflare Pages +- **バックエンド**: Railway または Heroku または AWS または GCP +- **データベース**: PostgreSQL (管理型) または自己管理 +- **CDN**: Cloudflare または AWS CloudFront + +## API設計 +- **アーキテクチャ**: RESTful API または GraphQL +- **ドキュメント**: OpenAPI/Swagger または GraphQL Schema +- **認証方式**: Bearer Token (JWT) または API Key + +## データ管理 +- **データベース設計**: 正規化 + 必要に応じて非正規化 +- **マイグレーション**: Prisma Migrate または TypeORM Migrations +- **バックアップ**: 自動バックアップ推奨 + +## セキュリティ +- **HTTPS**: 必須 +- **CORS**: 適切な設定 +- **認証**: JWT + Refresh Token パターン +- **バリデーション**: サーバーサイドバリデーション必須 +- **環境変数**: 機密情報の適切な管理 + +## パフォーマンス要件 +- **API応答時間**: 3秒以内 +- **フロントエンド初期表示**: 2秒以内 +- **データベースクエリ**: インデックス最適化 +- **キャッシュ戦略**: 適切なTTL設定 + +## 品質基準 +- **テストカバレッジ**: 80%以上推奨 +- **コード品質**: ESLint + Prettier +- **型安全性**: TypeScript strict mode +- **アクセシビリティ**: WCAG 2.1 AA準拠推奨 + +## ディレクトリ構造（推奨） + +``` +project/ +├── docs/ # ドキュメント +│ ├── spec/ # 要件定義 +│ ├── design/ # 設計文書 +│ └── tasks/ # タスク管理 +├── src/ # ソースコード +│ ├── components/ # UIコンポーネント +│ ├── services/ # ビジネスロジック +│ ├── types/ # 型定義 +│ └── utils/ # ユーティリティ +├── tests/ # テストファイル +├── prisma/ # データベーススキーマ +├── docker-compose.yml # 開発環境 +└── package.json # 依存関係 +``` + +## 使用方法 + +このデフォルト定義は以下の場合に参照されます： + +1. `docs/tech-stack.md` が存在しない +2. `CLAUDE.md` に技術スタック情報がない +3. 新規プロジェクトの初期設定 + +プロジェクト固有の技術選択がある場合は、`docs/tech-stack.md` を作成して上書きしてください。 \ No newline at end of file