zhongwei/gh-classmethod-tsumiki
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-29 18:09:29 +08:00
commit b3ad2e3943
28 changed files with 6966 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
commands/auto-debug.md Normal file
View File

@@ -0,0 +1,14 @@
---
description: テストエラーを解消するための自動デバッグプロセス。全テストケースの確認からエラー原因の調査、修正まで段階的に実行し、テストケースの成功率向上を目指します。
---
テストエラーを解消して。
最初に全テストケースの確認をタスク実行してテストケースのエラーをtodoにセットして
各対象毎に以下の作業を実施して
　 - タスクで詳細にテストのエラー原因を調る
　- 新たなタスクで /tsumiki:tdd-green を使って修正する
最後に全体のテストの成功率を確認してレポートして
ゴールはテストケースの成功数を上げること
NEVER: テストのスキップ
NEVER: 既存でテストケースの削除
#ultrathink

159
commands/direct-setup.md Normal file
View File

@@ -0,0 +1,159 @@
---
description: DIRECTタスクの設定作業を実行します。設計文書に基づいて環境構築、設定ファイル作成、依存関係のインストールなどを行います。
---
# direct-setup
## 目的
DIRECTタスクの設定作業を実行します。設計文書に基づいて環境構築、設定ファイル作成、依存関係のインストールなどを行います。
## 前提条件
- タスクIDが提供されている
- 関連する設計文書が存在する
- 必要な権限と環境が準備されている
## 実行内容
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ツールで読み込み
3. **設定作業の実行**
- @agent-symbol-searcher で既存の設定ファイルや環境変数を検索し、見つかったファイルをReadツールで読み込み
- 環境変数の設定
- 設定ファイルの作成・更新
- 依存関係のインストール
- データベースの初期化
- サービスの起動設定
- 権限の設定
4. **作業記録の作成**
- 実行したコマンドの記録
- 変更した設定の記録
- 遭遇した問題と解決方法の記録
## 出力先
作業記録は `docs/implements/{要件名}/{TASK-ID}/` ディレクトリに以下のファイルとして作成されます：
- `setup-report.md`: 設定作業実行記録
## 出力フォーマット例
````markdown
# {TASK-ID} 設定作業実行
## 作業概要
- **タスクID**: {TASK-ID}
- **作業内容**: {設定作業の概要}
- **実行日時**: {実行日時}
- **実行者**: {実行者}
## 設計文書参照
- **参照文書**: {参照した設計文書のリスト}
- **関連要件**: {REQ-XXX, REQ-YYY}
## 実行した作業
### 1. 環境変数の設定
```bash
# 実行したコマンド
export NODE_ENV=development
export DATABASE_URL=postgresql://localhost:5432/mydb
```
````
**設定内容**:
- NODE_ENV: 開発環境に設定
- DATABASE_URL: PostgreSQLデータベースのURL
### 2. 設定ファイルの作成
**作成ファイル**: `config/database.json`
```json
{
"development": {
"host": "localhost",
"port": 5432,
"database": "mydb"
}
}
```
### 3. 依存関係のインストール
```bash
# 実行したコマンド
npm install express pg
```
**インストール内容**:
- express: Webフレームワーク
- pg: PostgreSQLクライアント
### 4. データベースの初期化
```bash
# 実行したコマンド
createdb mydb
psql -d mydb -f database-schema.sql
```
**実行内容**:
- データベース作成
- スキーマの適用
## 作業結果
- [ ] 環境変数の設定完了
- [ ] 設定ファイルの作成完了
- [ ] 依存関係のインストール完了
- [ ] データベースの初期化完了
- [ ] サービスの起動設定完了
## 遭遇した問題と解決方法
### 問題1: {問題の概要}
- **発生状況**: {問題が発生した状況}
- **エラーメッセージ**: {エラーメッセージ}
- **解決方法**: {解決方法}
## 次のステップ
- `/tsumiki:direct-verify` を実行して設定を確認
- 必要に応じて設定の調整を実施
## 実行後の確認
- `docs/implements/{要件名}/{TASK-ID}/setup-report.md` ファイルが作成されていることを確認
- 設定が正しく適用されていることを確認
- 次のステップ（direct-verify）の準備が整っていることを確認
## ディレクトリ作成
実行前に必要なディレクトリを作成してください：
```bash
mkdir -p docs/implements/{要件名}/{TASK-ID}
```

427
commands/direct-verify.md Normal file
View File

@@ -0,0 +1,427 @@
---
description: DIRECTタスクで実行した設定作業の動作確認とテストを行います。設定が正しく適用され、システムが期待通りに動作することを確認します。
---
# direct-verify
## 目的
DIRECTタスクで実行した設定作業の動作確認とテストを行います。設定が正しく適用され、システムが期待通りに動作することを確認します。
## 前提条件
- `/tsumiki:direct-setup` が実行済み
- タスクIDが提供されている
- 設定作業の記録が存在する
## 実行内容
**【重要】**: direct-setupで作成されたファイルについて、コンパイルエラーや構文エラーが見つかった場合は自動的に解決を試行します。
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ツールで読み込み、設定作業の結果を確認
- 環境変数の確認
- 設定ファイルの内容確認
- 依存関係のインストール状況確認
- サービスの起動状況確認
3. **コンパイル・構文確認**
- TypeScript/JavaScript構文エラーチェック（該当する場合）
- 設定ファイルの構文確認（JSON, YAML等）
- SQL構文確認（該当する場合）
- 最低限のコンパイルエラー解消
4. **動作テストの実行**
- @agent-symbol-searcher で既存のテストケースや検証スクリプトを検索し、見つかったファイルをReadツールで読み込み
- 基本的な動作確認
- 接続テスト
- 権限の確認
- エラーケースの確認
5. **品質チェック**
- セキュリティ設定の確認
- パフォーマンス基準の確認
- ログの確認
## 出力先
確認記録は `docs/implements/{要件名}/{TASK-ID}/` ディレクトリに以下のファイルとして作成されます：
- `verify-report.md`: 設定確認・動作テスト記録
## 出力フォーマット例
````markdown
# {TASK-ID} 設定確認・動作テスト
## 確認概要
- **タスクID**: {TASK-ID}
- **確認内容**: {設定確認の概要}
- **実行日時**: {実行日時}
- **実行者**: {実行者}
## 設定確認結果
### 1. 環境変数の確認
```bash
# 実行したコマンド
echo $NODE_ENV
echo $DATABASE_URL
```
````
**確認結果**:
- [x] NODE_ENV: development (期待値: development)
- [x] DATABASE_URL: postgresql://localhost:5432/mydb (期待値: 正しいDB URL)
### 2. 設定ファイルの確認
**確認ファイル**: `config/database.json`
```bash
# 実行したコマンド
cat config/database.json | jq .
```
**確認結果**:
- [x] ファイルが存在する
- [x] JSON形式が正しい
- [x] 必要な設定項目が含まれている
## コンパイル・構文チェック結果
### 1. TypeScript/JavaScript構文チェック
```bash
# TypeScriptファイルがある場合
npx tsc --noEmit --skipLibCheck
# JavaScript構文チェック
node --check *.js
```
**チェック結果**:
- [x] TypeScript構文エラー: なし
- [x] JavaScript構文エラー: なし
- [x] import/require文: 正常
### 2. 設定ファイル構文チェック
```bash
# JSON設定ファイルの構文チェック
cat config/*.json | jq empty
# YAML設定ファイルの構文チェック（該当する場合）
yamllint config/*.yml
```
**チェック結果**:
- [x] JSON構文: 正常
- [x] YAML構文: 正常（該当する場合）
- [x] 設定項目の妥当性: 確認済み
### 3. SQL構文チェック（該当する場合）
```bash
# SQL構文の基本チェック
psql -d mydb --single-transaction --set ON_ERROR_STOP=on -f schema.sql --dry-run
```
**チェック結果**:
- [x] SQL構文: 正常
- [x] テーブル定義: 正常
- [x] 制約定義: 正常
### 3. 依存関係の確認
```bash
# 実行したコマンド
npm list express pg
```
**確認結果**:
- [x] express: インストール済み
- [x] pg: インストール済み
### 4. データベース接続テスト
```bash
# 実行したコマンド
psql -d mydb -c "SELECT 1;"
```
**確認結果**:
- [x] データベース接続成功
- [x] クエリ実行成功
## 動作テスト結果
### 1. 基本動作テスト
```bash
# 実行したテストコマンド
node -e "console.log('Hello, World!');"
```
**テスト結果**:
- [x] Node.js実行環境: 正常
- [x] 基本的なJavaScript実行: 正常
### 2. データベース接続テスト
```javascript
// テストスクリプト
const { Pool } = require('pg');
const pool = new Pool({
connectionString: process.env.DATABASE_URL,
});
pool.query('SELECT NOW()', (err, res) => {
if (err) {
console.error('Error:', err);
} else {
console.log('Connected:', res.rows[0]);
}
pool.end();
});
```
**テスト結果**:
- [x] データベース接続: 正常
- [x] クエリ実行: 正常
- [x] 接続終了: 正常
### 3. セキュリティ設定テスト
```bash
# 実行したコマンド
ls -la config/
ps aux | grep node
```
**テスト結果**:
- [x] 設定ファイルの権限: 適切
- [x] プロセスの実行権限: 適切
- [x] 機密情報の保護: 適切
## 品質チェック結果
### パフォーマンス確認
- [x] 起動時間: 2秒以内
- [x] メモリ使用量: 256MB以内
- [x] CPU使用率: 10%以内
### ログ確認
- [x] エラーログ: 異常なし
- [x] 警告ログ: 問題なし
- [x] 情報ログ: 適切に出力
## 全体的な確認結果
- [x] 設定作業が正しく完了している
- [x] 全ての動作テストが成功している
- [x] 品質基準を満たしている
- [x] 次のタスクに進む準備が整っている
## 発見された問題と解決
### 構文エラー・コンパイルエラーの解決
**自動解決を試行する問題**:
- TypeScript/JavaScript構文エラー
- JSON/YAML構文エラー
- 基本的なSQL構文エラー
- import/require文の問題
### 問題1: {問題があれば記載}
- **問題内容**: {問題の詳細}
- **発見方法**: {構文チェック/コンパイル/動作テスト}
- **重要度**: {高/中/低}
- **自動解決**: {実行した解決コマンド・修正内容}
- **解決結果**: {解決済み/手動対応が必要}
### 解決実行ログ
```bash
# 実行した解決コマンド例
# 構文エラー修正
sed -i 's/typo/correct/g' config.js
# 依存関係の修正
npm install missing-package
# 設定ファイル修正
jq '.port = 3000' config.json > temp.json && mv temp.json config.json
```
**解決結果**:
- [x] 問題1: 解決済み
- [x] 問題2: 解決済み
- [ ] 問題3: 手動対応が必要（詳細は推奨事項に記載）
## 推奨事項
- {改善提案があれば記載}
- {最適化の提案があれば記載}
## 次のステップ
- タスクの完了報告
- 関連するタスクの開始準備
- 必要に応じて設定の微調整
````
## 実行後の確認
- `docs/implements/{要件名}/{TASK-ID}/verify-report.md` ファイルが作成されていることを確認
- 全ての確認項目が完了していることを確認
- 問題が発見された場合は適切に対処されていることを確認
- タスクの完了条件を満たしていることを確認
- 次のタスクに進む準備が整っていることを確認
## ディレクトリ確認
`docs/implements/{要件名}/{TASK-ID}/` ディレクトリが存在することを確認してください（direct-setupで作成済みのはず）
## タスクの完了マーキング
品質チェックが十分で、全ての確認項目がクリアされた場合は、**自動的に**tasksディレクトリの該当するタスクファイルに完了マークを付けてください。
### 完了条件
以下の条件を全て満たす場合にタスクを完了とマークします：
- [ ] 全ての設定確認項目がクリア
- [ ] コンパイル・構文チェックが成功（エラーがすべて解決済み）
- [ ] 全ての動作テストが成功
- [ ] 品質チェック項目が基準を満たしている
- [ ] 発見された問題が適切に対処されている
- [ ] セキュリティ設定が適切
- [ ] パフォーマンス基準を満たしている
### 完了マークの付け方
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` を作成または更新してください。
### 更新内容
1. **現在のREADME.mdの確認**: 既存のREADME.mdがある場合は内容を確認
2. **完了したタスクの情報を追加**:
- 実装した機能の概要
- 設定手順
- 動作確認方法
- 使用方法
3. **プロジェクト全体の情報を更新**:
- セットアップ手順
- 依存関係
- 環境要件
- 開発・運用手順
### README.md更新フォーマット例
```markdown
# プロジェクト名
## 概要
{プロジェクトの概要}
## 完了した機能
### {TASK-ID}: {タスク名}
- **実装日**: {実装日}
- **概要**: {機能の概要}
- **設定内容**: {設定した内容}
- **動作確認**: {動作確認の結果}
## セットアップ手順
### 前提条件
- {必要な環境・ツール}
### インストール
```bash
# 依存関係のインストール
{インストールコマンド}
# 環境変数の設定
{環境変数設定}
````
### 起動方法
```bash
# 開発サーバーの起動
{起動コマンド}
```
## 設定
### 環境変数
- `{環境変数名}`: {説明}
### 設定ファイル
- `{設定ファイルパス}`: {説明}
## 使用方法
{使用方法の説明}
## 開発
### 開発環境の準備
{開発環境の準備手順}
### テスト
{テストの実行方法}
## トラブルシューティング
### よくある問題
- **問題**: {問題の内容}
- **解決方法**: {解決方法}
## 更新履歴
- {日付}: {TASK-ID} {変更内容}
```
### 実行手順
1. 現在のREADME.mdを確認（存在しない場合は新規作成）
2. 完了したタスクの情報を追加
3. 必要に応じて他のセクションも更新
4. 変更内容をコミット
```

573
commands/init-tech-stack.md Normal file
View File

@@ -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`）
### ❌ 推奨技術が見つからない
**原因**: 特殊な技術要件や制約
**対処**: カスタマイズモードで手動選択
```
このように、段階的なヒアリングとインテリジェントな推奨機能により、プロジェクトに最適な技術スタック定義が自動生成される仕組みを作成しました。

240
commands/kairo-design.md Normal file
View File

@@ -0,0 +1,240 @@
---
description: 承認された要件定義書に基づいて、技術設計文書を生成する。データフロー図、TypeScriptインターフェース、データベーススキーマ、APIエンドポイントを含む包括的な設計を行います。
---
# kairo-design
## 目的
承認された要件定義書に基づいて、技術設計文書を生成する。データフロー図、TypeScriptインターフェース、データベーススキーマ、APIエンドポイントを含む包括的な設計を行う。
## 前提条件
- `docs/spec/` に要件定義書が存在する
- 要件がユーザによって承認されている
## 事前準備
1. **追加ルールの読み込み**
- `docs/rule` ディレクトリが存在する場合は読み込み
- `docs/rule/kairo` ディレクトリが存在する場合は読み込み
- `docs/rule/kairo/design` ディレクトリが存在する場合は読み込み
- 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用
## 実行内容
**【信頼性レベル指示】**:
各項目について、元の資料（EARS要件定義書・設計文書含む）との照合状況を以下の信号でコメントしてください：
- 🔵 **青信号**: EARS要件定義書・設計文書を参考にしてほぼ推測していない場合
- 🟡 **黄信号**: EARS要件定義書・設計文書から妥当な推測の場合
- 🔴 **赤信号**: EARS要件定義書・設計文書にない推測の場合
2. **技術スタック定義の読み込み**
- `docs/tech-stack.md` が存在する場合は読み込み
- 存在しない場合は `CLAUDE.md` から技術スタックセクションを読み込み
- どちらも存在しない場合は `.claude/commands/tech-stack.md` のデフォルト定義を使用
3. **要件の分析**
- @agent-symbol-searcher で要件定義書を検索し、見つかったファイルをReadツールで読み込み
- @agent-symbol-searcher で関連する既存設計文書を確認し、見つかったファイルをReadツールで読み込み
- 読み込んだ技術スタック定義に基づいて技術選択を決定
- 機能要件と非機能要件を整理する
- システムの境界を明確にする
4. **アーキテクチャ設計**
- システム全体のアーキテクチャを決定
- フロントエンド/バックエンドの分離
- マイクロサービスの必要性を検討
5. **データフロー図の作成**
- Mermaid記法でデータフローを可視化
- ユーザーインタラクションの流れ
- システム間のデータの流れ
6. **TypeScriptインターフェースの定義**
- NEVER 対象言語がTypeScriptで無い場合はそれに合わせたファイル形式に変更する。インタフェース定義が不要なら生成しない
- エンティティの型定義
- APIリクエスト/レスポンスの型定義
- 共通型の定義
8. **データベーススキーマの設計**
- NEVER 対象がデータベーススキーマが不要の場合は生成しない
- テーブル定義
- リレーションシップ
- インデックス戦略
- 正規化レベルの決定
9. **APIエンドポイントの設計**
- NEVER 対象にAPIではない場合、または既存のAPIを利用する場合は生成しない
- RESTful API設計
- エンドポイントの命名規則
- HTTPメソッドの適切な使用
- リクエスト/レスポンスの構造
10. **ファイルの作成**
- `docs/design/{要件名}/` ディレクトリに以下を作成：
- `architecture.md` - アーキテクチャ概要
- `dataflow.md` - データフロー図
- `interfaces.ts` - TypeScript型定義
- `database-schema.sql` - DBスキーマ
- `api-endpoints.md` - API仕様
## 出力フォーマット例
### architecture.md
```markdown
# {要件名} アーキテクチャ設計
## システム概要
{システムの概要説明}
## アーキテクチャパターン
- パターン: {選択したパターン}
- 理由: {選択理由}
## コンポーネント構成
### フロントエンド
- フレームワーク: {使用フレームワーク}
- 状態管理: {状態管理方法}
### バックエンド
- フレームワーク: {使用フレームワーク}
- 認証方式: {認証方法}
### データベース
- DBMS: {使用するDBMS}
- キャッシュ: {キャッシュ戦略}
```
### dataflow.md
```markdown
# データフロー図
## ユーザーインタラクションフロー
\`\`\`mermaid
flowchart TD
A[ユーザー] --> B[フロントエンド]
B --> C[API Gateway]
C --> D[バックエンド]
D --> E[データベース]
\`\`\`
## データ処理フロー
\`\`\`mermaid
sequenceDiagram
participant U as ユーザー
participant F as フロントエンド
participant B as バックエンド
participant D as データベース
U->>F: アクション
F->>B: APIリクエスト
B->>D: クエリ実行
D-->>B: 結果返却
B-->>F: レスポンス
F-->>U: 画面更新
\`\`\`
```
### interfaces.ts
```typescript
// エンティティ定義
export interface User {
id: string;
email: string;
name: string;
createdAt: Date;
updatedAt: Date;
}
// APIリクエスト/レスポンス
export interface CreateUserRequest {
email: string;
name: string;
password: string;
}
export interface ApiResponse<T> {
success: boolean;
data?: T;
error?: {
code: string;
message: string;
};
}
```
### database-schema.sql
```sql
-- ユーザーテーブル
CREATE TABLE users (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
email VARCHAR(255) UNIQUE NOT NULL,
name VARCHAR(255) NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
-- インデックス
CREATE INDEX idx_users_email ON users(email);
```
### api-endpoints.md
```markdown
# API エンドポイント仕様
## 認証
### POST /auth/login
リクエスト:
\`\`\`json
{
"email": "user@example.com",
"password": "password"
}
\`\`\`
レスポンス:
\`\`\`json
{
"success": true,
"data": {
"token": "jwt-token",
"user": { ... }
}
}
\`\`\`
## ユーザー管理
### GET /users/:id
### POST /users
### PUT /users/:id
### DELETE /users/:id
```
## 実行後の確認
- @agent-symbol-searcher で作成した設計と既存システムとの整合性を確認
- 作成したファイルの一覧を表示
- 設計の主要なポイントをサマリーで表示
- ユーザに確認を促すメッセージを表示

379
commands/kairo-implement.md Normal file
View File

@@ -0,0 +1,379 @@
---
description: 分割されたタスクを順番に、またはユーザが指定したタスクを実装します。既存のTDDコマンドを活用して品質の高い実装を行います。
---
あなたは実装担当者です。残タスクを調べて 指定されたコマンドを駆使して実装をしてください
# kairo-implement
## 目的
分割されたタスクを順番に、またはユーザが指定したタスクを実装する。既存のTDDコマンドを活用して品質の高い実装を行う。
## 前提条件
- `docs/tasks/{要件名}-tasks.md` にタスク一覧が存在する
- ユーザがタスクの実装を承認している
- 既存のTDDコマンドが利用可能である
- 実装用のワークスペースが設定されている
- task_id は　`TASK-{4桁の数字}` (例 TASK-0001 ) である
## 実行内容
**【信頼性レベル指示】**:
各項目について、元の資料（EARS要件定義書・設計文書含む）との照合状況を以下の信号でコメントしてください：
- 🔵 **青信号**: EARS要件定義書・設計文書を参考にしてほぼ推測していない場合
- 🟡 **黄信号**: EARS要件定義書・設計文書から妥当な推測の場合
- 🔴 **赤信号**: EARS要件定義書・設計文書にない推測の場合
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を確認
- 指定がない場合は、依存関係に基づいて次のタスクを自動選択
- 選択したタスクの詳細を表示
- 読み込んだ技術スタック定義に基づいて実装方針を決定
4. **依存関係の確認**
- @agent-symbol-searcher で依存タスクの状態を検索し、見つかったタスクファイルをReadツールで読み込み
- 依存タスクが完了しているか確認
- 未完了の依存タスクがある場合は警告
5. **実装ディレクトリの準備**
- 現在のワークスペースで作業を行う
- 必要に応じてディレクトリ構造を確認
6. **実装タイプの判定**
- タスクの性質を分析（コード実装 vs 準備作業）
- 実装方式を決定（TDD vs 直接作業）
7. **実装プロセスの実行**
### A. **TDDプロセス**（コード実装タスク用）
a. **要件定義** - `@task general-purpose /tsumiki:tdd-requirements`
```
Task実行: TDD要件定義フェーズ
目的: タスクの詳細要件を記述し、受け入れ基準を明確化する
コマンド: /tsumiki:tdd-requirements
実行方式: 個別Task実行
```
b. **テストケース作成** - `@task general-purpose /tsumiki:tdd-testcases`
```
Task実行: TDDテストケース作成フェーズ
目的: 単体テストケースを作成し、エッジケースを考慮する
コマンド: /tsumiki:tdd-testcases
実行方式: 個別Task実行
```
c. **テスト実装** - `@task general-purpose /tsumiki:tdd-red`
```
Task実行: TDDレッドフェーズ
目的: 失敗するテストを実装し、テストが失敗することを確認する
コマンド: /tsumiki:tdd-red
実行方式: 個別Task実行
```
d. **最小実装** - `@task general-purpose /tsumiki:tdd-green`
```
Task実行: TDDグリーンフェーズ
目的: テストが通る最小限の実装を行い、過度な実装を避ける
コマンド: /tsumiki:tdd-green
実行方式: 個別Task実行
```
e. **リファクタリング** - `@task general-purpose /tsumiki:tdd-refactor`
```
Task実行: TDDリファクタリングフェーズ
目的: コードの品質向上と保守性の改善を行う
コマンド: /tsumiki:tdd-refactor
実行方式: 個別Task実行
```
f. **品質確認** - `@task general-purpose /tsumiki:tdd-verify-complete`
```
Task実行: TDD品質確認フェーズ
目的: 実装の完成度を確認し、不足があればc-fを繰り返す
コマンド: /tsumiki:tdd-verify-complete
実行方式: 個別Task実行
```
### B. **直接作業プロセス**（準備作業タスク用）
a. **準備作業の実行** - `@task general-purpose /tsumiki:direct-setup`
```
Task実行: 直接作業実行フェーズ
目的: ディレクトリ作成、設定ファイル作成、依存関係のインストール、環境設定を行う
作業内容:
- ディレクトリ作成
- 設定ファイル作成
- 依存関係のインストール
- 環境設定
実行方式: 個別Task実行
```
b. **作業結果の確認** - `@task general-purpose /tsumiki:direct-verify`
```
Task実行: 直接作業確認フェーズ
目的: 作業完了の検証と成果物確認を行う
作業内容:
- 作業完了の検証
- 期待された成果物の確認
- 次のタスクへの準備状況確認
実行方式: 個別Task実行
```
8. **タスクの完了処理**
- タスクのステータスを更新（タスクファイルのチェックボックスにチェックを入れる）
- 実装結果をドキュメント化
- 次のタスクを提案
## 実行フロー
```mermaid
flowchart TD
A[タスク選択] --> B{依存関係OK?}
B -->|No| C[警告表示]
B -->|Yes| D[実装開始]
D --> E{タスクタイプ判定}
E -->|コード実装| F[TDDプロセス]
E -->|準備作業| G[直接作業プロセス]
F --> F1[tdd-requirements]
F1 --> F2[tdd-testcases]
F2 --> F3[tdd-red]
F3 --> F4[tdd-green]
F4 --> F5[tdd-refactor]
F5 --> F6[tdd-verify-complete]
F6 --> F7{品質OK?}
F7 -->|No| F3
F7 -->|Yes| H[タスク完了]
G --> G1[準備作業実行]
G1 --> G2[作業結果確認]
G2 --> H
H --> I{他のタスク?}
I -->|Yes| A
I -->|No| J[全タスク完了]
```
## コマンド実行例
```bash
# 全タスクを順番に実装
$ claude code kairo-implement --all
# 特定のタスクを実装
$ claude code kairo-implement --task {{task_id}}
# 並行実行可能なタスクを一覧表示
$ claude code kairo-implement --list-parallel
# 現在の進捗を表示
$ claude code kairo-implement --status
```
## 実装タイプ判定基準
### TDDプロセス（コード実装タスク）
以下の条件に当てはまるタスク：
- 新しいコンポーネント、サービス、フック等の実装
- 既存コードの機能追加・修正
- ビジネスロジックの実装
- API実装
**例**: TaskService実装、UIコンポーネント作成、状態管理実装
### 直接作業プロセス（準備作業タスク）
以下の条件に当てはまるタスク：
- プロジェクト初期化・環境構築
- ディレクトリ構造作成
- 設定ファイル作成・更新
- 依存関係のインストール
- ツール設定・設定
**例**: プロジェクト初期化、データベース設定、開発環境設定
## 個別Task実行アプローチ
### Task実行の方針
各実装ステップを個別のTaskとして実行することで、以下のメリットが得られます：
1. **独立性**: 各ステップが独立して実行され、エラー発生時の切り分けが容易
2. **再実行性**: 特定のステップのみ再実行が可能
3. **並列性**: 依存関係のないステップは並列実行可能
4. **追跡性**: 各ステップの実行状況と結果が明確に記録される
### Task実行パターン
```bash
# TDDプロセスの場合
@task general-purpose /tsumiki:tdd-requirements
@task general-purpose /tsumiki:tdd-testcases
@task general-purpose /tsumiki:tdd-red
@task general-purpose /tsumiki:tdd-green
@task general-purpose /tsumiki:tdd-refactor
@task general-purpose /tsumiki:tdd-verify-complete
# 直接作業プロセスの場合
@task general-purpose /tsumiki:direct-setup
@task general-purpose /tsumiki:direct-verify
```
## 実装時の注意事項
### TDDプロセス用
1. **テストファースト**
- 必ずテストを先に書く
- テストが失敗することを確認してから実装
2. **インクリメンタルな実装**
- 一度に全てを実装しない
- 小さなステップで進める
3. **継続的な品質確認**
- 各ステップで品質を確認
- 技術的負債を作らない
### 直接作業プロセス用
1. **作業の段階的実行**
- 依存関係を考慮した順序で実行
- 各ステップの完了を確認
2. **設定の検証**
- 作成した設定ファイルの動作確認
- 環境の正常性チェック
3. **ドキュメントの更新**
- 実装と同時にドキュメントも更新
- 他の開発者が理解できるように
## 出力フォーマット
### タスク開始時（TDDプロセス）
```
🚀 タスク {{task_id}}: {{task_name}} の実装を開始します
📋 タスク詳細:
- 要件: REQ-101, REQ-102
- 依存: {{依存タスクID}} ✅
- 推定時間: 4時間
- 実装タイプ: TDDプロセス
🔄 TDDプロセスを開始します...
```
### タスク開始時（直接作業プロセス）
```
🚀 タスク {{task_id}}: {{task_name}} の実装を開始します
📋 タスク詳細:
- 要件: REQ-402, REQ-006
- 依存: {{依存タスクID}} ✅
- 推定時間: 3時間
- 実装タイプ: 直接作業プロセス
🔧 準備作業を開始します...
```
### 各ステップ完了時（TDD）
```
✅ Task 1/6: @task /tsumiki:tdd-requirements 完了
ファイル: docs/implements/{要件名}/{{task_id}}/{要件名}-requirements.md
Task実行結果: 要件定義書作成完了
🏃 Task 2/6: @task /tsumiki:tdd-testcases 実行中...
Task実行: TDDテストケース作成フェーズを開始
```
### 各ステップ完了時（直接作業）
```
✅ Task 1/2: @task /tsumiki:direct-setup 完了
作成ファイル: 8個、設定更新: 3個
Task実行結果: 準備作業実行完了
🏃 Task 2/2: @task /tsumiki:direct-verify 実行中...
Task実行: 直接作業確認フェーズを開始
```
### タスク完了時（TDD）
```
🎉 タスク {{task_id}} が完了しました！
✅ タスクファイルのチェックボックスを更新しました
- [ ] **タスク完了** → [x] **タスク完了**
📊 実装サマリー:
- 実装タイプ: TDDプロセス (個別Task実行)
- 実行Taskステップ: 6個 (全て成功)
- 作成ファイル: 12個
- テストケース: 25個 (全て成功)
- カバレッジ: 95%
- 所要時間: 3時間45分
📝 次の推奨タスク:
- {{次のタスクID}}: {{次のタスク名}}
- {{関連タスクID}}: {{関連タスク名}}（依存関係あり）
続けて実装しますか？ (y/n)
```
### タスク完了時（直接作業）
```
🎉 タスク {{task_id}} が完了しました！
✅ タスクファイルのチェックボックスを更新しました
- [ ] **タスク完了** → [x] **タスク完了**
📊 実装サマリー:
- 実装タイプ: 直接作業プロセス (個別Task実行)
- 実行Taskステップ: 2個 (全て成功)
- 作成ファイル: 8個
- 設定更新: 3個
- 環境確認: 正常
- 所要時間: 2時間30分
📝 次の推奨タスク:
- {{次のタスクID}}: {{次のタスク名}}
- {{関連タスクID}}: {{関連タスク名}}（依存関係あり）
続けて実装しますか？ (y/n)
```
## エラーハンドリング
- 依存タスク未完了: 警告を表示し、確認を求める
- テスト失敗: 詳細なエラー情報を表示
- ファイル競合: バックアップを作成してから上書き
## 実行後の確認
- 実装したファイルの一覧を表示
- テスト結果のサマリーを表示
- 残りのタスクと進捗率を表示
- 次のタスクの提案を表示

473
commands/kairo-requirements.md Normal file
View File

@@ -0,0 +1,473 @@
---
description: ユーザから提供された要件の概要を分析し、EARS（Easy Approach to Requirements Syntax）記法を使用して詳細な受け入れ基準を含む要件定義書を作成します。
---
# kairo-requirements
## 目的
既存プロジェクトの情報を収集・分析し、ユーザから要件をヒアリングして、EARS（Easy Approach to Requirements Syntax）記法を使用した詳細な受け入れ基準を含む要件定義書を作成する。
ユーザに要件をヒアリングするときは一問一答形式で選択肢から選ぶか自由入力を可能にする
## 前提条件
- 既存プロジェクト（コードベース、設計文書等）が存在する
- `docs/spec/` ディレクトリが存在する（なければ作成）
## 実行フロー
### Phase 0: 既存プロジェクト情報の網羅的収集
**【信頼性レベル指示】**:
各項目について、元の資料（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要件定義書・設計文書・ユーザヒアリングにない推測の場合
## 出力フォーマット例
### 1. requirements.md（メインファイル）
```markdown
# {要件名} 要件定義書
## 概要
{要件の概要}
## 関連文書
- **ユーザストーリー**: [📖 {要件名}-user-stories.md]({要件名}-user-stories.md)
- **受け入れ基準**: [✅ {要件名}-acceptance-criteria.md]({要件名}-acceptance-criteria.md)
## 機能要件（EARS記法）
**【信頼性レベル凡例】**:
- 🔵 **青信号**: EARS要件定義書・設計文書・ユーザヒアリングを参考にした確実な要件
- 🟡 **黄信号**: EARS要件定義書・設計文書・ユーザヒアリングから妥当な推測による要件
- 🔴 **赤信号**: EARS要件定義書・設計文書・ユーザヒアリングにない推測による要件
### 通常要件
- REQ-001: システムは {通常の動作} しなければならない 🔵 *EARS要件定義書第3章より*
- REQ-002: システムは {通常の動作} しなければならない 🟡 *設計文書から妥当な推測*
- REQ-003: システムは {通常の動作} しなければならない 🔵 *ユーザヒアリング2024-01-15より*
### 条件付き要件
- REQ-101: {条件} の場合、システムは {動作} しなければならない 🔵 *ユーザー要件・API仕様書より*
- REQ-102: {条件} の場合、システムは {動作} しなければならない 🔴 *設計文書にない推測*
- REQ-103: {条件} の場合、システムは {動作} しなければならない 🟡 *ユーザヒアリング内容から妥当な推測*
### 状態要件
- REQ-201: {状態} にある場合、システムは {動作} しなければならない 🟡 *DB設計書から妥当な推測*
### オプション要件
- REQ-301: システムは {オプション機能} してもよい 🔵 *CLAUDE.md技術制約より*
### 制約要件
- REQ-401: システムは {制約事項} しなければならない 🔵 *CLAUDE.md・既存実装より*
## 非機能要件
### パフォーマンス
- NFR-001: {パフォーマンス要件} 🟡 *CLAUDE.md制約から妥当な推測*
### セキュリティ
- NFR-101: {セキュリティ要件} 🔵 *セキュリティ設計書・実装より*
### ユーザビリティ
- NFR-201: {ユーザビリティ要件} 🔴 *ユーザー要件にない推測*
- NFR-202: {ユーザビリティ要件} 🔵 *ユーザヒアリング2024-01-20 UX要望より*
## Edgeケース
### エラー処理
- EDGE-001: {エラーケース} 🟡 *既存実装から妥当な推測*
### 境界値
- EDGE-101: {境界値ケース} 🔵 *API仕様書・テストケースより*
```
### 2. user-stories.md（詳細なユーザストーリー）
```markdown
# {要件名} ユーザストーリー
## 概要
このドキュメントは{要件名}機能の詳細なユーザストーリーを記載します。
## ユーザー種別の定義
### プライマリユーザー
- **エンドユーザー**: {エンドユーザーの詳細説明}
- **管理者**: {管理者の詳細説明}
- **開発者**: {開発者の詳細説明}
### セカンダリユーザー
- **システム管理者**: {システム管理者の詳細説明}
- **外部システム**: {外部システムの詳細説明}
## ユーザストーリー
**【信頼性レベル凡例】**:
- 🔵 **青信号**: EARS要件定義書・設計文書・ユーザヒアリングを参考にした確実なストーリー
- 🟡 **黄信号**: EARS要件定義書・設計文書・ユーザヒアリングから妥当な推測によるストーリー
- 🔴 **赤信号**: EARS要件定義書・設計文書・ユーザヒアリングにない推測によるストーリー
### 📚 エピック1: {大きな機能グループ} 🔵 *ユーザヒアリング2024-01-15より*
#### ストーリー1.1: {具体的なストーリー名} 🔵 *EARS要件定義書・ユーザヒアリングより*
**ユーザストーリー**:
- **私は** {ユーザー種別} **として**
- **{具体的な状況・コンテキスト} において**
- **{実現したい行動・操作} をしたい**
- **そうすることで** {得られる価値・解決される問題}
**詳細説明**:
- **背景**: {なぜこの機能が必要なのか}
- **前提条件**: {このストーリーの前提となる状況}
- **利用シーン**: {具体的な利用場面の例}
- **期待する体験**: {ユーザーが期待する体験の詳細}
**関連要件**: REQ-001, REQ-002
**優先度**: 高/中/低
**見積もり**: {ストーリーポイントまたは工数}
#### ストーリー1.2: {具体的なストーリー名} 🟡 *設計文書から妥当な推測*
{同様の形式で記載}
### 📚 エピック2: {大きな機能グループ} 🔴 *既存資料にない推測*
{同様の形式で記載}
## ユーザージャーニー
### ジャーニー1: {代表的な利用フロー} 🔵 *ユーザヒアリング業務フローより*
```mermaid
journey
title {ユーザージャーニーのタイトル}
section {フェーズ1}
{アクション1}: 5: {ユーザー種別}
{アクション2}: 3: {ユーザー種別}
section {フェーズ2}
{アクション3}: 4: {ユーザー種別}
{アクション4}: 5: {ユーザー種別}
```
**詳細**:
1. **{アクション1}**: {詳細な説明}
2. **{アクション2}**: {詳細な説明}
## ペルソナ定義
### ペルソナ1: {代表的ユーザー名} 🔵 *ユーザヒアリング2024-01-18 ペルソナ調査より*
- **基本情報**: {年齢、職業、技術レベル等}
- **ゴール**: {このユーザーが達成したいこと}
- **課題**: {現在抱えている問題}
- **行動パターン**: {典型的な行動の特徴}
- **利用環境**: {使用するデバイス、環境等}
## 非機能的ユーザー要求
### ユーザビリティ要求
- **学習容易性**: {初回利用時の学習コスト}
- **効率性**: {熟練後の作業効率}
- **記憶しやすさ**: {再利用時の記憶のしやすさ}
- **エラー対応**: {エラー時の対応しやすさ}
- **満足度**: {主観的な満足度}
### アクセシビリティ要求
- **視覚**: {視覚障害者への配慮}
- **聴覚**: {聴覚障害者への配慮}
- **運動**: {運動機能障害者への配慮}
- **認知**: {認知障害者への配慮}
```
### 3. acceptance-criteria.md（受け入れ基準）
```markdown
# {要件名} 受け入れ基準
## 概要
このドキュメントは{要件名}機能の受け入れ基準とテスト項目を記載します。
## 機能テスト基準
**【信頼性レベル凡例】**:
- 🔵 **青信号**: EARS要件定義書・設計文書・ユーザヒアリングを参考にした確実なテスト基準
- 🟡 **黄信号**: EARS要件定義書・設計文書・ユーザヒアリングから妥当な推測によるテスト基準
- 🔴 **赤信号**: EARS要件定義書・設計文書・ユーザヒアリングにない推測によるテスト基準
### REQ-001: {要件名} の受け入れ基準 🔵 *EARS要件定義書・既存テスト仕様より*
**Given（前提条件）**:
- {テスト実行前の状態}
- {必要な初期データ}
**When（実行条件）**:
- {実行するアクション}
- {入力するデータ}
**Then（期待結果）**:
- {期待される出力・状態}
- {確認すべき副作用}
**テストケース**:
- [ ] 正常系: {正常なケースの詳細}
- [ ] 異常系: {異常なケースの詳細}
- [ ] 境界値: {境界値テストの詳細}
### REQ-002: {要件名} の受け入れ基準 🟡 *ユーザヒアリング要望から妥当な推測*
{同様の形式で記載}
## 非機能テスト基準
### パフォーマンステスト
**NFR-001: {パフォーマンス要件} 🔵 *CLAUDE.md制約・ユーザヒアリングより***
- [ ] 応答時間: {具体的な時間基準}
- [ ] スループット: {処理量の基準}
- [ ] 同時接続数: {同時利用者数の基準}
- [ ] リソース使用量: {CPU・メモリ使用量の基準}
**テスト方法**:
- 負荷テストツール: {使用するツール}
- テストシナリオ: {具体的なテスト手順}
- 合格基準: {定量的な合格ライン}
### セキュリティテスト
**NFR-101: {セキュリティ要件} 🟡 *セキュリティ設計書から妥当な推測***
- [ ] 認証: {認証機能のテスト項目}
- [ ] 認可: {権限制御のテスト項目}
- [ ] データ保護: {データ暗号化のテスト項目}
- [ ] 脆弱性: {セキュリティ脆弱性のテスト項目}
## ユーザビリティテスト基準
### UX/UIテスト
- [ ] 直感的操作性: {操作の分かりやすさ}
- [ ] レスポンシブデザイン: {各デバイスでの表示}
- [ ] アクセシビリティ: {WCAG 2.1準拠}
- [ ] エラーメッセージ: {分かりやすいエラー表示}
**テスト方法**:
- ユーザビリティテスト: {実施方法}
- A/Bテスト: {比較テストの方法}
- アクセシビリティチェック: {使用するツール}
## Edgeケーステスト基準
### EDGE-001: {エラーケース} の受け入れ基準 🔴 *既存資料にない推測*
**テストシナリオ**:
- {異常な状況の設定}
- {期待されるエラーハンドリング}
- {ユーザーへの適切な通知}
**合格基準**:
- [ ] システムがクラッシュしない
- [ ] 適切なエラーメッセージが表示される
- [ ] データの整合性が保たれる
- [ ] 復旧可能な状態を維持する
## 統合テスト基準
### システム間連携テスト
- [ ] 外部API連携: {外部システムとの連携テスト}
- [ ] データベース連携: {DB操作の整合性テスト}
- [ ] ファイルシステム: {ファイル操作のテスト}
## リグレッションテスト基準
### 既存機能影響確認
- [ ] 既存機能の動作確認: {影響範囲の特定と確認}
- [ ] パフォーマンス劣化確認: {既存機能の性能確認}
- [ ] セキュリティ設定確認: {セキュリティ機能の継続確認}
## 受け入れテスト実行チェックリスト
### テスト実行前
- [ ] テスト環境の準備完了
- [ ] テストデータの準備完了
- [ ] テストツールの準備完了
- [ ] 実行担当者の確認完了
### テスト実行中
- [ ] 全機能テストの実行
- [ ] 全非機能テストの実行
- [ ] 問題発見時の記録
- [ ] 修正後の再テスト
### テスト完了後
- [ ] テスト結果の記録
- [ ] 残存問題の整理
- [ ] 受け入れ可否の判定
- [ ] ステークホルダーへの報告
```
## ヒアリング質問例
### 既存設計確認系質問
- "現在のCLAUDE.mdで定義されている{制約事項}について、実際の運用で問題ないでしょうか？"
- "技術スタック（{技術名}）について、変更希望や追加制約はありますか？"
- "既存の{機能名}機能で、想定しているユースケースに追加はありますか？"
- "パフォーマンス要件（{具体的な数値}）で、実際の業務に支障はないでしょうか？"
### 詳細化系質問
- "{機能名}で、具体的にどのような操作フローを想定していますか？"
- "データの入力項目について、{項目名}以外に必要なものはありますか？"
- "エラーが発生した場合、どのような通知・対応を期待しますか？"
- "外部システムとの連携で、{システム名}との接続は必要ですか？"
### 追加要件系質問
- "現在の設計にない機能で、実現したいものはありますか？"
- "レポート・分析機能は必要ですか？必要な場合、どのような情報が欲しいですか？"
- "モバイルアプリでの利用は想定していますか？"
- "複数人での同時利用・権限管理は必要ですか？"
### 影響確認系質問
- "この新機能により、既存の{機能名}の変更は許容できますか？"
- "データ移行が発生する場合、どの程度の作業時間が許容できますか？"
- "パフォーマンスへの影響で、許容できる範囲を教えてください"
- "セキュリティ要件で、追加で考慮すべき点はありますか？"
## 実行後の確認
- Phase 0で収集した既存プロジェクト情報のサマリーを表示
- Phase 1でのヒアリング結果と既存情報との差分を明確化
- 作成した3つのファイルのパスを表示
- `docs/spec/{要件名}-requirements.md`
- `docs/spec/{要件名}-user-stories.md`
- `docs/spec/{要件名}-acceptance-criteria.md`
- 既存要件からの変更点・追加点の件数を報告
- 各ファイル内のリンクが正しく設定されていることを確認
- 既存設計書・実装との整合性確認を促すメッセージを表示

67
commands/kairo-task-verify.md Normal file
View File

@@ -0,0 +1,67 @@
---
description: 作成されたタスクファイルの内容を確認し、出力フォーマット例に沿った情報が抜けていたら追加します。
---
# kairo-task-verify
## 目的
作成されたタスクファイルの内容を確認し、出力フォーマット例に沿った情報が抜けていたら追加する。
## 前提条件
- `docs/tasks/{要件名}-tasks.md` が存在する
- kairo-tasksコマンドによってタスクファイルが作成済みである
## 実行内容
**【信頼性レベル指示】**:
各項目について、元の資料（EARS要件定義書・設計文書含む）との照合状況を以下の信号でコメントしてください：
- 🔵 **青信号**: EARS要件定義書・設計文書を参考にしてほぼ推測していない場合
- 🟡 **黄信号**: EARS要件定義書・設計文書から妥当な推測の場合
- 🔴 **赤信号**: EARS要件定義書・設計文書にない推測の場合
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ツールで読み込み
4. **出力フォーマット例との比較**
- @agent-symbol-searcher で関連するタスクフォーマットを検索し、見つかったファイルをReadツールで読み込み
- kairo-tasksコマンドファイルをReadツールで読み込み、出力フォーマット例を確認
- 作成されたタスクファイルに不足している情報を特定
5. **不足情報の追加**
以下の項目が含まれているか確認し、不足していれば追加：
- 概要セクション（全タスク数、推定作業時間、クリティカルパス）
- 各タスクのチェックボックス
- タスクタイプ（TDD/DIRECT）の明記
- 要件リンク
- 依存タスク
- 実装詳細
- テスト要件
- UI/UX要件（フロントエンドタスクの場合）
- エラーハンドリング要件
- 完了条件
- 実行順序（Mermaidガントチャート）
- サブタスクテンプレート情報
6. **ファイルの更新**
- 不足している情報を追加してファイルを更新
## 実行後の確認
- 更新したファイルのパスを表示
- 追加した情報の概要を表示
- タスクファイルが完全になったことを確認

169
commands/kairo-tasks.md Normal file
View File

@@ -0,0 +1,169 @@
---
description: 設計文書に基づいて実装タスクを1日単位の粒度で分割し、1ヶ月単位のフェーズに整理します。各フェーズ毎に個別のタスクファイルを作成し、依存関係を考慮した適切な順序で管理します。
---
# kairo-tasks
## 目的
設計文書に基づいて実装タスクを1日単位の粒度で分割し、1ヶ月単位のフェーズに整理する。各フェーズ毎に個別のタスクファイルを作成し、依存関係を考慮した適切な順序で管理する。
## 前提条件
- `docs/design/{要件名}/` に設計文書が存在する
- 設計がユーザによって承認されている（または承認が省略されている）
- `docs/tasks/` ディレクトリが存在する（なければ作成）
- 思考は英語で実施。ファイルは日本語で記述
- NEVER: task_id は　`TASK-{4桁の数字}` (例 TASK-0001 )にする
## 実行内容
**【信頼性レベル指示】**:
各項目について、元の資料（EARS要件定義書・設計文書含む）との照合状況を以下の信号でコメントしてください：
- 🔵 **青信号**: EARS要件定義書・設計文書を参考にしてほぼ推測していない場合
- 🟡 **黄信号**: EARS要件定義書・設計文書から妥当な推測の場合
- 🔴 **赤信号**: EARS要件定義書・設計文書にない推測の場合
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ツールで読み込み
- 読み込んだ技術スタック定義に基づいて実装技術を特定
4. **既存タスクファイルの確認**
- @agent-symbol-searcher で既存タスクIDを検索し、見つかったタスクファイルをReadツールで読み込み
- 既存の`docs/tasks/{要件名}-*.md`ファイルをReadツールで読み込み
- 使用済みタスク番号（TASK-0000形式）を抽出
- 新規タスクで重複しない番号を割り当て
5. **タスクの洗い出し**
- 基盤タスク（DB設定、環境構築など）
- バックエンドタスク（API実装）
- フロントエンドタスク（UI実装）
- 画面のグループ毎に細かく分割する
- 統合タスク（E2Eテストなど）
6. **依存関係の分析**
- タスク間の依存関係を明確化
- 並行実行可能なタスクを識別
- クリティカルパスを特定
7. **タスクの詳細化**
各タスクに以下を含める：
- タスクID（TASK-0000形式）
- タスク名
- タスクタイプ（TDD/DIRECT）
- **TDD**: コーディング、ビジネスロジック実装、UI実装、テスト実装など開発作業
- **DIRECT**: 環境構築、設定ファイル作成、ドキュメント作成、ビルド設定など準備作業
- 要件へのリンク
- 依存タスク
- 実装詳細
- 単体テスト要件
- 統合テスト要件
- UI/UX要件（該当する場合）
- ローディング状態
- エラー表示
- モバイル対応
- アクセシビリティ要件
8. **タスクの順序付け**
- 依存関係に基づいて実行順序を決定
- マイルストーンを設定
- 並行実行可能なタスクをグループ化
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の詳細タスク
- （以下、フェーズ数に応じて継続）
- `docs/tasks/{要件名}-overview.md`: 全体概要とフェーズ一覧
- 各タスクにチェックボックスを追加してタスクの完了状況を追跡可能にする
- 各タスクには 要件名 の定義を含める
## 出力ファイル構造
作成するファイル:
- `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. `/tsumiki:tdd-requirements` - 詳細要件定義
2. `/tsumiki:tdd-testcases` - テストケース作成
3. `/tsumiki:tdd-red` - テスト実装（失敗）
4. `/tsumiki:tdd-green` - 最小実装
5. `/tsumiki:tdd-refactor` - リファクタリング
6. `/tsumiki:tdd-verify-complete` - 品質確認
### DIRECTタスク
1. `/tsumiki:direct-setup` - 直接実装・設定
2. `/tsumiki:direct-verify` - 動作確認・品質確認
## 実行フロー
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作成
## 品質基準
- **フェーズ制限**: 180時間以内、500行未満
- **タスク粒度**: 1日8時間単位
- **番号管理**: TASK-0000形式、重複なし
- **完了条件**: 各タスクにチェックボックスと完了条件
- **依存関係**: 前タスク完了後の実行順序明記

497
commands/rev-design.md Normal file
View File

@@ -0,0 +1,497 @@
---
description: 既存のコードベースから技術設計文書を逆生成します。実装されたアーキテクチャ、データフロー、API仕様、データベーススキーマ、TypeScriptインターフェースを分析し、設計書として文書化します。
---
# rev-design
## 目的
既存のコードベースから技術設計文書を逆生成する。実装されたアーキテクチャ、データフロー、API仕様、データベーススキーマ、TypeScriptインターフェースを分析し、設計書として文書化する。
## 前提条件
- 分析対象のコードベースが存在する
- `docs/reverse/` ディレクトリが存在する（なければ作成）
- 可能であれば事前に `/tsumiki:rev-tasks` を実行済み
## 実行内容
1. **アーキテクチャの分析**
- プロジェクト構造からアーキテクチャパターンを特定
- レイヤー構成の確認（MVC、Clean Architecture等）
- マイクロサービス構成の有無
- フロントエンド/バックエンドの分離状況
2. **データフローの抽出**
- ユーザーインタラクションの流れ
- API呼び出しの流れ
- データベースアクセスパターン
- 状態管理の流れ
3. **API仕様の抽出**
- エンドポイント一覧の生成
- リクエスト/レスポンス構造の分析
- 認証・認可方式の確認
- エラーレスポンス形式
4. **データベーススキーマの逆生成**
- テーブル定義の抽出
- リレーションシップの分析
- インデックス設定の確認
- 制約条件の抽出
5. **TypeScript型定義の整理**
- エンティティ型の抽出
- API型の抽出
- 共通型の整理
- 型の依存関係分析
6. **コンポーネント設計の分析**
- UIコンポーネント階層
- Propsインターフェース
- 状態管理の設計
- ルーティング設計
7. **ファイルの作成**
- `docs/reverse/{プロジェクト名}-architecture.md` - アーキテクチャ概要
- `docs/reverse/{プロジェクト名}-dataflow.md` - データフロー図
- `docs/reverse/{プロジェクト名}-api-specs.md` - API仕様
- `docs/reverse/{プロジェクト名}-database.md` - DB設計
- `docs/reverse/{プロジェクト名}-interfaces.ts` - 型定義集約
## 出力フォーマット例
### architecture.md
```markdown
# {プロジェクト名} アーキテクチャ設計（逆生成）
## 分析日時
{実行日時}
## システム概要
### 実装されたアーキテクチャ
- **パターン**: {特定されたアーキテクチャパターン}
- **フレームワーク**: {使用フレームワーク}
- **構成**: {発見された構成}
### 技術スタック
#### フロントエンド
- **フレームワーク**: {React/Vue/Angular等}
- **状態管理**: {Redux/Zustand/Pinia等}
- **UI ライブラリ**: {Material-UI/Ant Design等}
- **スタイリング**: {CSS Modules/styled-components等}
#### バックエンド
- **フレームワーク**: {Express/NestJS/FastAPI等}
- **認証方式**: {JWT/Session/OAuth等}
- **ORM/データアクセス**: {TypeORM/Prisma/Sequelize等}
- **バリデーション**: {Joi/Yup/zod等}
#### データベース
- **DBMS**: {PostgreSQL/MySQL/MongoDB等}
- **キャッシュ**: {Redis/Memcached等 or なし}
- **接続プール**: {実装されているか}
#### インフラ・ツール
- **ビルドツール**: {Webpack/Vite/Rollup等}
- **テストフレームワーク**: {Jest/Vitest/Pytest等}
- **コード品質**: {ESLint/Prettier/SonarQube等}
## レイヤー構成
### 発見されたレイヤー
```
{実際のディレクトリ構造}
```
### レイヤー責務分析
- **プレゼンテーション層**: {実装状況}
- **アプリケーション層**: {実装状況}
- **ドメイン層**: {実装状況}
- **インフラストラクチャ層**: {実装状況}
## デザインパターン
### 発見されたパターン
- **Dependency Injection**: {実装されているか}
- **Repository Pattern**: {実装されているか}
- **Factory Pattern**: {使用箇所}
- **Observer Pattern**: {使用箇所}
- **Strategy Pattern**: {使用箇所}
## 非機能要件の実装状況
### セキュリティ
- **認証**: {実装方式}
- **認可**: {実装方式}
- **CORS設定**: {設定状況}
- **HTTPS対応**: {対応状況}
### パフォーマンス
- **キャッシュ**: {実装状況}
- **データベース最適化**: {インデックス等}
- **CDN**: {使用状況}
- **画像最適化**: {実装状況}
### 運用・監視
- **ログ出力**: {実装状況}
- **エラートラッキング**: {実装状況}
- **メトリクス収集**: {実装状況}
- **ヘルスチェック**: {実装状況}
```
### dataflow.md
```markdown
# データフロー図（逆生成）
## ユーザーインタラクションフロー
### 認証フロー
\`\`\`mermaid
sequenceDiagram
participant U as ユーザー
participant F as フロントエンド
participant B as バックエンド
participant D as データベース
U->>F: ログイン情報入力
F->>B: POST /auth/login
B->>D: ユーザー検証
D-->>B: ユーザー情報
B-->>F: JWTトークン
F-->>U: ログイン完了
\`\`\`
### データ取得フロー
\`\`\`mermaid
flowchart TD
A[ユーザーアクション] --> B[Reactコンポーネント]
B --> C[useQueryフック]
C --> D[Axios HTTP Client]
D --> E[API Gateway/Express]
E --> F[コントローラー]
F --> G[サービス層]
G --> H[リポジトリ層]
H --> I[データベース]
I --> H
H --> G
G --> F
F --> E
E --> D
D --> C
C --> B
B --> J[UI更新]
\`\`\`
## 状態管理フロー
### {使用されている状態管理ライブラリ} フロー
\`\`\`mermaid
flowchart LR
A[コンポーネント] --> B[Action Dispatch]
B --> C[Reducer/Store]
C --> D[State更新]
D --> A
\`\`\`
## エラーハンドリングフロー
\`\`\`mermaid
flowchart TD
A[エラー発生] --> B{エラー種別}
B -->|認証エラー| C[リダイレクト to ログイン]
B -->|ネットワークエラー| D[リトライ機能]
B -->|バリデーションエラー| E[フォームエラー表示]
B -->|サーバーエラー| F[エラートースト表示]
\`\`\`
```
### api-specs.md
```markdown
# API仕様書（逆生成）
## ベースURL
\`{発見されたベースURL}\`
## 認証方式
{発見された認証方式の詳細}
## エンドポイント一覧
### 認証関連
#### POST /auth/login
**説明**: ユーザーログイン
**リクエスト**:
\`\`\`typescript
{
email: string;
password: string;
}
\`\`\`
**レスポンス**:
\`\`\`typescript
{
success: boolean;
data: {
token: string;
user: {
id: string;
email: string;
name: string;
}
};
}
\`\`\`
**エラーレスポンス**:
\`\`\`typescript
{
success: false;
error: {
code: string;
message: string;
}
}
\`\`\`
#### POST /auth/logout
**説明**: ユーザーログアウト
**ヘッダー**:
\`\`\`
Authorization: Bearer {token}
\`\`\`
### {その他のエンドポイント}
## エラーコード一覧
| コード | メッセージ | 説明 |
|--------|------------|------|
| AUTH_001 | Invalid credentials | 認証情報が無効 |
| AUTH_002 | Token expired | トークンが期限切れ |
| VALID_001 | Validation failed | バリデーションエラー |
## レスポンス共通形式
### 成功レスポンス
\`\`\`typescript
{
success: true;
data: T; // 型は endpoint によって変動
}
\`\`\`
### エラーレスポンス
\`\`\`typescript
{
success: false;
error: {
code: string;
message: string;
details?: any;
}
}
\`\`\`
```
### database.md
```markdown
# データベース設計（逆生成）
## スキーマ概要
### テーブル一覧
{発見されたテーブル一覧}
### ER図
\`\`\`mermaid
erDiagram
USERS {
uuid id PK
varchar email UK
varchar name
timestamp created_at
timestamp updated_at
}
POSTS {
uuid id PK
uuid user_id FK
varchar title
text content
timestamp created_at
timestamp updated_at
}
USERS ||--o{ POSTS : creates
\`\`\`
## テーブル詳細
### users テーブル
\`\`\`sql
{実際のCREATE TABLE文}
\`\`\`
**カラム説明**:
- \`id\`: {説明}
- \`email\`: {説明}
- \`name\`: {説明}
**インデックス**:
- \`idx_users_email\`: email カラムの検索用
### {その他のテーブル}
## 制約・関係性
### 外部キー制約
{発見された外部キー制約}
### ユニーク制約
{発見されたユニーク制約}
## データアクセスパターン
### よく使用されるクエリ
{コードから発見されたクエリパターン}
### パフォーマンス考慮事項
{発見されたインデックス戦略}
```
### interfaces.ts
```typescript
// ======================
// エンティティ型定義
// ======================
export interface User {
id: string;
email: string;
name: string;
createdAt: Date;
updatedAt: Date;
}
export interface Post {
id: string;
userId: string;
title: string;
content: string;
createdAt: Date;
updatedAt: Date;
user?: User;
}
// ======================
// API型定義
// ======================
export interface LoginRequest {
email: string;
password: string;
}
export interface LoginResponse {
success: boolean;
data: {
token: string;
user: User;
};
}
export interface ApiResponse<T = any> {
success: boolean;
data?: T;
error?: {
code: string;
message: string;
details?: any;
};
}
// ======================
// コンポーネントProps型
// ======================
export interface LoginFormProps {
onSubmit: (data: LoginRequest) => void;
loading?: boolean;
error?: string;
}
// ======================
// 状態管理型
// ======================
export interface AuthState {
user: User | null;
token: string | null;
isAuthenticated: boolean;
loading: boolean;
}
// ======================
// 設定型
// ======================
export interface AppConfig {
apiBaseUrl: string;
tokenStorageKey: string;
supportedLanguages: string[];
}
```
## 分析アルゴリズム
### 1. ファイル走査・パターンマッチング
- AST解析による関数・クラス・インターフェース抽出
- 正規表現による設定ファイル解析
- ディレクトリ構造からのアーキテクチャ推定
### 2. API仕様の自動生成
- Express/NestJS ルート定義の解析
- FastAPI スキーマ定義の解析
- TypeScript型定義からのリクエスト/レスポンス推定
### 3. データベーススキーマの抽出
- マイグレーションファイルの解析
- ORM モデル定義の解析
- SQL ファイルの解析
## 実行コマンド例
```bash
# フル分析（全設計書生成）
claude code rev-design
# 特定の設計書のみ生成
claude code rev-design --target architecture
claude code rev-design --target api
claude code rev-design --target database
# 特定のディレクトリを分析
claude code rev-design --path ./backend
# 出力形式指定
claude code rev-design --format markdown,openapi
```
## 実行後の確認
- 生成された設計書ファイルの一覧を表示
- 抽出されたAPI数、テーブル数、型定義数等の統計情報を表示
- 不足している設計要素や推奨改善点を提示
- 次のリバースエンジニアリングステップ（要件定義生成等）を提案

389
commands/rev-requirements.md Normal file
View File

@@ -0,0 +1,389 @@
---
description: 既存のコードベースから要件定義書を逆生成します。実装された機能を分析し、EARS（Easy Approach to Requirements Syntax）記法を用いて機能要件、非機能要件、ユーザーストーリーを抽出・文書化します。
---
# rev-requirements
## 目的
既存のコードベースから要件定義書を逆生成する。実装された機能を分析し、EARS（Easy Approach to Requirements Syntax）記法を用いて機能要件、非機能要件、ユーザーストーリーを抽出・文書化する。
## 前提条件
- 分析対象のコードベースが存在する
- `docs/reverse/` ディレクトリが存在する（なければ作成）
- 可能であれば事前に `/tsumiki:rev-tasks` および `/tsumiki:rev-design` を実行済み
## 実行内容
1. **機能の特定と分析**
- UI コンポーネントから画面機能を抽出
- API エンドポイントからビジネス機能を特定
- データベーススキーマからデータ要件を推定
- テストコードから期待動作を確認
2. **ユーザーストーリーの逆算**
- 実装された機能からユーザーの意図を推定
- WHO（ユーザー種別）の特定
- WHAT（実現したいこと）の抽出
- WHY（得られる価値）の推定
3. **EARS記法による要件分類**
- **通常要件（SHALL）**: 標準的な機能実装から抽出
- **条件付き要件（WHEN/IF-THEN）**: 条件分岐ロジックから抽出
- **状態要件（WHERE）**: 状態管理実装から抽出
- **オプション要件（MAY）**: 設定可能機能から抽出
- **制約要件（MUST）**: バリデーション・制限ロジックから抽出
4. **非機能要件の推定**
- パフォーマンス要件：実装されたキャッシュ、最適化から推定
- セキュリティ要件：認証・認可実装から抽出
- ユーザビリティ要件：UI/UX実装から抽出
- 運用要件：ログ、監視実装から抽出
5. **Edgeケースの特定**
- エラーハンドリング実装から異常系要件を抽出
- バリデーション実装から境界値要件を抽出
- テストケースから想定されるエラーケースを抽出
6. **受け入れ基準の生成**
- 実装されたテストから受け入れ基準を逆算
- 未実装のテストケースを推奨事項として提示
7. **ファイルの作成**
- `docs/reverse/{プロジェクト名}-requirements.md` として保存
## 出力フォーマット例
```markdown
# {プロジェクト名} 要件定義書（逆生成）
## 分析概要
**分析日時**: {実行日時}
**対象コードベース**: {パス}
**抽出要件数**: {機能要件数}個の機能要件、{非機能要件数}個の非機能要件
**信頼度**: {分析の信頼度} % （実装カバレッジに基づく）
## システム概要
### 推定されたシステム目的
{実装された機能から推測されるシステムの目的}
### 対象ユーザー
{UIコンポーネントや機能から推定されるユーザー種別}
## ユーザーストーリー
### ストーリー1: ユーザー認証
- **である** 未登録・既存ユーザー **として**
- **私は** システムに安全にログイン **をしたい**
- **そうすることで** 個人的な情報やサービスにアクセスできる
**実装根拠**:
- `LoginForm.tsx` - ログインフォーム実装
- `POST /auth/login` - 認証API実装
- `useAuth` フック - 認証状態管理
### ストーリー2: {その他のストーリー}
{実装された機能から推定される追加のユーザーストーリー}
## 機能要件（EARS記法）
### 通常要件
#### REQ-001: ユーザー認証
システムは有効なメールアドレスとパスワードでのユーザーログインを提供しなければならない。
**実装根拠**:
- `auth.service.ts:login()` メソッド
- `POST /auth/login` エンドポイント
- JWTトークン発行実装
#### REQ-002: セッション管理
システムはログイン後のユーザーセッションを管理しなければならない。
**実装根拠**:
- JWT トークンによるセッション管理
- `useAuth` フックでの状態管理
- ローカルストレージでのトークン永続化
### 条件付き要件
#### REQ-101: 認証失敗時の処理
無効な認証情報が提供された場合、システムは適切なエラーメッセージを表示しなければならない。
**実装根拠**:
- `auth.controller.ts` のエラーハンドリング
- `LoginForm.tsx` のエラー表示実装
#### REQ-102: トークン期限切れ時の処理
JWTトークンが期限切れの場合、システムはユーザーを再ログインページにリダイレクトしなければならない。
**実装根拠**:
- `axios.interceptors` での401エラーハンドリング
- 自動ログアウト機能の実装
### 状態要件
#### REQ-201: ログイン状態での表示
ユーザーがログイン状態にある場合、システムは認証済みユーザー向けのUIを表示しなければならない。
**実装根拠**:
- `useAuth` フックでの認証状態確認
- 認証状態による条件分岐レンダリング
### オプション要件
#### REQ-301: ログイン状態の記憶
システムはユーザーのログイン状態を記憶してもよい。
**実装根拠**:
- ローカルストレージでのトークン保存
- 自動ログイン機能の実装
### 制約要件
#### REQ-401: パスワード要件
システムはパスワードに最小8文字の制約を設けなければならない。
**実装根拠**:
- フロントエンドバリデーション実装
- `yup` スキーマでの制約定義
#### REQ-402: レート制限
システムはログイン試行に対してレート制限を設けなければならない。
**実装根拠**:
- `express-rate-limit` ミドルウェアの実装
## 非機能要件
### パフォーマンス
#### NFR-001: ログイン応答時間
システムは通常のログイン処理を2秒以内に完了しなければならない。
**実装根拠**:
- データベースインデックス設定
- 効率的なクエリ実装
#### NFR-002: 同時ユーザー数
システムは同時に100ユーザーのアクセスを処理できなければならない。
**推定根拠**:
- 接続プール設定
- サーバー構成
### セキュリティ
#### NFR-101: 認証トークン暗号化
システムはJWTトークンを適切に暗号化しなければならない。
**実装根拠**:
- `jsonwebtoken` ライブラリの使用
- 秘密鍵による署名実装
#### NFR-102: HTTPS通信
システムは本番環境でHTTPS通信を強制しなければならない。
**実装根拠**:
- SSL設定ファイル
- HTTPS リダイレクト実装
### ユーザビリティ
#### NFR-201: レスポンシブデザイン
システムはモバイルデバイスでも利用可能でなければならない。
**実装根拠**:
- CSS メディアクエリの実装
- レスポンシブUIコンポーネント
#### NFR-202: アクセシビリティ
システムは基本的なアクセシビリティ要件を満たさなければならない。
**実装根拠**:
- ARIA属性の使用
- セマンティックHTML構造
### 運用性
#### NFR-301: ログ出力
システムは重要な操作をログに記録しなければならない。
**実装根拠**:
- `winston` ログライブラリの使用
- 構造化ログの実装
#### NFR-302: エラー追跡
システムは発生したエラーを追跡可能でなければならない。
**実装根拠**:
- エラーハンドリング実装
- ログ出力による追跡機能
## Edgeケース
### エラー処理
#### EDGE-001: ネットワーク障害
ネットワーク接続が不安定な場合のリトライ処理
**実装根拠**:
- `axios` のリトライ設定
- エラートースト表示
#### EDGE-002: サーバーダウン
バックエンドサーバーが利用できない場合の処理
**実装根拠**:
- フォールバック機能
- エラーページ表示
### 境界値
#### EDGE-101: 最大文字数制限
入力フィールドの最大文字数制限
**実装根拠**:
- フォームバリデーション実装
- データベース制約
#### EDGE-102: 空文字・null値処理
空文字やnull値に対する適切な処理
**実装根拠**:
- バリデーション実装
- デフォルト値設定
## 受け入れ基準
### 実装済み機能テスト
- [x] ユーザーログイン機能
- [x] 有効な認証情報でのログイン成功
- [x] 無効な認証情報でのログイン失敗
- [x] エラーメッセージの適切な表示
- [x] セッション管理機能
- [x] ログイン状態の維持
- [x] ログアウト機能
- [x] トークン期限切れ処理
### 推奨追加テスト
- [ ] **パフォーマンステスト**
- [ ] ログイン応答時間測定
- [ ] 同時アクセス負荷テスト
- [ ] **セキュリティテスト**
- [ ] SQLインジェクション対策テスト
- [ ] XSS対策テスト
- [ ] CSRF対策テスト
- [ ] **アクセシビリティテスト**
- [ ] スクリーンリーダー対応テスト
- [ ] キーボード操作テスト
## 推定されていない要件
### 不明確な部分
以下の要件は実装から推定が困難なため、ステークホルダーとの確認が必要：
1. **ビジネス要件**
- システムの使用目的の詳細
- 対象ユーザーの詳細な属性
- 収益モデルや事業目標
2. **運用要件**
- バックアップ・復旧要件
- SLA（サービスレベル合意）
- 監視・アラート要件
3. **法的・コンプライアンス要件**
- データ保護規則への準拠
- 業界固有の規制要件
### 推奨される次ステップ
1. **ステークホルダーインタビュー** - 推定された要件の確認
2. **ユーザビリティテスト** - 実際のユーザビリティ要件の確認
3. **パフォーマンステスト** - 非機能要件の検証
4. **セキュリティ監査** - セキュリティ要件の詳細検証
## 分析の制約事項
### 信頼度に影響する要因
- **コメント不足**: 開発者の意図を推定で補完
- **テストカバレッジ**: {%}% - 未テスト部分の要件は推定
- **ドキュメント不足**: 外部仕様書が存在しない
- **レガシーコード**: 古い実装パターンによる推定の難しさ
### 推定の根拠
- **強い根拠**: 実装 + テスト + 明確な動作
- **中程度の根拠**: 実装 + 部分的テスト
- **弱い根拠**: 実装のみ、推定で補完
```
## 要件抽出アルゴリズム
### 1. 機能要件の抽出プロセス
```
1. APIエンドポイント → ビジネス機能要件
2. UIコンポーネント → ユーザーインターフェース要件
3. データベーススキーマ → データ要件
4. バリデーション実装 → 制約要件
5. 条件分岐 → 条件付き要件
```
### 2. 非機能要件の推定プロセス
```
1. 設定ファイル + ライブラリ → パフォーマンス・セキュリティ要件
2. UI実装パターン → ユーザビリティ要件
3. ログ・監視実装 → 運用要件
4. テスト実装 → 品質要件
```
### 3. ユーザーストーリーの逆算プロセス
```
1. 画面遷移フロー → ユーザージャーニー
2. フォーム・入力項目 → ユーザーアクション
3. データの CRUD操作 → ユーザーニーズ
4. 権限・ロール実装 → ユーザー種別
```
## 実行コマンド例
```bash
# フル分析（全要件抽出）
claude code rev-requirements
# 特定の要件カテゴリのみ抽出
claude code rev-requirements --target functional
claude code rev-requirements --target non-functional
claude code rev-requirements --target user-stories
# 信頼度フィルタ
claude code rev-requirements --confidence high
claude code rev-requirements --confidence medium
# 特定のディレクトリを分析
claude code rev-requirements --path ./src
# 出力形式指定
claude code rev-requirements --format markdown,json
```
## 実行後の確認
- 抽出された要件数（機能要件・非機能要件）を表示
- 分析の信頼度と根拠の強さを報告
- 推定が困難な要件や確認が必要な項目を提示
- ステークホルダー確認のための質問リストを生成
- 次の推奨アクション（テスト追加、ドキュメント整備等）を提案

622
commands/rev-specs.md Normal file
View File

@@ -0,0 +1,622 @@
---
description: 既存のコードベースから包括的なテストケースと仕様書を逆生成します。実装されたビジネスロジック、API動作、UI コンポーネントの動作を分析し、不足しているテストケースを特定・生成し、仕様書として文書化します。
---
# rev-specs
## 目的
既存のコードベースから包括的なテストケースと仕様書を逆生成する。実装されたビジネスロジック、API動作、UI コンポーネントの動作を分析し、不足しているテストケースを特定・生成し、仕様書として文書化する。
## 前提条件
- 分析対象のコードベースが存在する
- `docs/reverse/` ディレクトリが存在する（なければ作成）
- 可能であれば事前に `/tsumiki:rev-requirements`, `/tsumiki:rev-design` を実行済み
## 実行内容
1. **既存テストの分析**
- 単体テスト（Unit Test）の実装状況確認
- 統合テスト（Integration Test）の実装状況確認
- E2Eテスト（End-to-End Test）の実装状況確認
- テストカバレッジの測定
2. **実装コードからテストケースの逆生成**
- 関数・メソッドの引数・戻り値からのテストケース生成
- 条件分岐からの境界値テスト生成
- エラーハンドリングからの異常系テスト生成
- データベース操作からのデータテスト生成
3. **API仕様からテストケースの生成**
- 各エンドポイントの正常系テスト
- 認証・認可テスト
- バリデーションエラーテスト
- HTTPステータスコードテスト
4. **UI コンポーネントからテストケースの生成**
- コンポーネントレンダリングテスト
- ユーザーインタラクションテスト
- 状態変更テスト
- プロパティ変更テスト
5. **パフォーマンス・セキュリティテストケースの生成**
- 負荷テストシナリオ
- セキュリティ脆弱性テスト
- レスポンス時間テスト
6. **テスト仕様書の生成**
- テスト計画書
- テストケース一覧
- テスト環境仕様
- テスト手順書
7. **ファイルの作成**
- `docs/reverse/{プロジェクト名}-test-specs.md` - テスト仕様書
- `docs/reverse/{プロジェクト名}-test-cases.md` - テストケース一覧
- `docs/reverse/tests/` - 生成されたテストコード
## 出力フォーマット例
### test-specs.md
```markdown
# {プロジェクト名} テスト仕様書（逆生成）
## 分析概要
**分析日時**: {実行日時}
**対象コードベース**: {パス}
**テストカバレッジ**: {現在のカバレッジ}%
**生成テストケース数**: {生成数}個
**実装推奨テスト数**: {推奨数}個
## 現在のテスト実装状況
### テストフレームワーク
- **単体テスト**: {Jest/Vitest/pytest等}
- **統合テスト**: {Supertest/TestContainers等}
- **E2Eテスト**: {Cypress/Playwright等}
- **コードカバレッジ**: {istanbul/c8等}
### テストカバレッジ詳細
| ファイル/ディレクトリ | 行カバレッジ | 分岐カバレッジ | 関数カバレッジ |
|---------------------|-------------|-------------|-------------|
| src/auth/ | 85% | 75% | 90% |
| src/users/ | 60% | 45% | 70% |
| src/components/ | 40% | 30% | 50% |
| **全体** | **65%** | **55%** | **75%** |
### テストカテゴリ別実装状況
#### 単体テスト
- [x] **認証サービス**: auth.service.spec.ts
- [x] **ユーザーサービス**: user.service.spec.ts
- [ ] **データ変換ユーティリティ**: 未実装
- [ ] **バリデーションヘルパー**: 未実装
#### 統合テスト
- [x] **認証API**: auth.controller.spec.ts
- [ ] **ユーザー管理API**: 未実装
- [ ] **データベース操作**: 未実装
#### E2Eテスト
- [ ] **ユーザーログインフロー**: 未実装
- [ ] **データ操作フロー**: 未実装
- [ ] **エラーハンドリング**: 未実装
## 生成されたテストケース
### API テストケース
#### POST /auth/login - ログイン認証
**正常系テスト**
```typescript
describe('POST /auth/login', () => {
it('有効な認証情報でログイン成功', async () => {
const response = await request(app)
.post('/auth/login')
.send({
email: 'test@example.com',
password: 'password123'
});
expect(response.status).toBe(200);
expect(response.body.success).toBe(true);
expect(response.body.data.token).toBeDefined();
expect(response.body.data.user.email).toBe('test@example.com');
});
it('JWTトークンが正しい形式で返される', async () => {
const response = await request(app)
.post('/auth/login')
.send(validCredentials);
const token = response.body.data.token;
expect(token).toMatch(/^[A-Za-z0-9-_]+\.[A-Za-z0-9-_]+\.[A-Za-z0-9-_]+$/);
});
});
```
**異常系テスト**
```typescript
describe('POST /auth/login - 異常系', () => {
it('無効なメールアドレスでエラー', async () => {
const response = await request(app)
.post('/auth/login')
.send({
email: 'invalid-email',
password: 'password123'
});
expect(response.status).toBe(400);
expect(response.body.success).toBe(false);
expect(response.body.error.code).toBe('VALIDATION_ERROR');
});
it('存在しないユーザーでエラー', async () => {
const response = await request(app)
.post('/auth/login')
.send({
email: 'nonexistent@example.com',
password: 'password123'
});
expect(response.status).toBe(401);
expect(response.body.error.code).toBe('INVALID_CREDENTIALS');
});
it('パスワード間違いでエラー', async () => {
const response = await request(app)
.post('/auth/login')
.send({
email: 'test@example.com',
password: 'wrongpassword'
});
expect(response.status).toBe(401);
expect(response.body.error.code).toBe('INVALID_CREDENTIALS');
});
});
```
**境界値テスト**
```typescript
describe('POST /auth/login - 境界値', () => {
it('最小文字数パスワードでテスト', async () => {
// 8文字（最小要件）
const response = await request(app)
.post('/auth/login')
.send({
email: 'test@example.com',
password: '12345678'
});
expect(response.status).toBe(200);
});
it('最大文字数メールアドレスでテスト', async () => {
// 255文字（最大要件）
const longEmail = 'a'.repeat(243) + '@example.com';
const response = await request(app)
.post('/auth/login')
.send({
email: longEmail,
password: 'password123'
});
expect(response.status).toBe(400);
});
});
```
### UIコンポーネントテストケース
#### LoginForm コンポーネント
**レンダリングテスト**
```typescript
import { render, screen } from '@testing-library/react';
import { LoginForm } from './LoginForm';
describe('LoginForm', () => {
it('必要な要素が表示される', () => {
render(<LoginForm onSubmit={jest.fn()} />);
expect(screen.getByLabelText('メールアドレス')).toBeInTheDocument();
expect(screen.getByLabelText('パスワード')).toBeInTheDocument();
expect(screen.getByRole('button', { name: 'ログイン' })).toBeInTheDocument();
});
it('初期状態でエラーメッセージが非表示', () => {
render(<LoginForm onSubmit={jest.fn()} />);
expect(screen.queryByText(/エラー/)).not.toBeInTheDocument();
});
});
```
**ユーザーインタラクションテスト**
```typescript
import { render, screen, fireEvent, waitFor } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
describe('LoginForm - ユーザーインタラクション', () => {
it('フォーム送信時にonSubmitが呼ばれる', async () => {
const mockSubmit = jest.fn();
render(<LoginForm onSubmit={mockSubmit} />);
await userEvent.type(screen.getByLabelText('メールアドレス'), 'test@example.com');
await userEvent.type(screen.getByLabelText('パスワード'), 'password123');
await userEvent.click(screen.getByRole('button', { name: 'ログイン' }));
expect(mockSubmit).toHaveBeenCalledWith({
email: 'test@example.com',
password: 'password123'
});
});
it('バリデーションエラー時に送信されない', async () => {
const mockSubmit = jest.fn();
render(<LoginForm onSubmit={mockSubmit} />);
await userEvent.click(screen.getByRole('button', { name: 'ログイン' }));
expect(mockSubmit).not.toHaveBeenCalled();
expect(screen.getByText('メールアドレスは必須です')).toBeInTheDocument();
});
});
```
### サービス層テストケース
#### AuthService 単体テスト
```typescript
import { AuthService } from './auth.service';
import { UserRepository } from './user.repository';
jest.mock('./user.repository');
describe('AuthService', () => {
let authService: AuthService;
let mockUserRepository: jest.Mocked<UserRepository>;
beforeEach(() => {
mockUserRepository = new UserRepository() as jest.Mocked<UserRepository>;
authService = new AuthService(mockUserRepository);
});
describe('login', () => {
it('有効な認証情報でユーザー情報とトークンを返す', async () => {
const mockUser = {
id: '1',
email: 'test@example.com',
hashedPassword: 'hashed_password'
};
mockUserRepository.findByEmail.mockResolvedValue(mockUser);
jest.spyOn(authService, 'verifyPassword').mockResolvedValue(true);
jest.spyOn(authService, 'generateToken').mockReturnValue('mock_token');
const result = await authService.login('test@example.com', 'password');
expect(result).toEqual({
user: { id: '1', email: 'test@example.com' },
token: 'mock_token'
});
});
it('存在しないユーザーでエラーをスロー', async () => {
mockUserRepository.findByEmail.mockResolvedValue(null);
await expect(
authService.login('nonexistent@example.com', 'password')
).rejects.toThrow('Invalid credentials');
});
});
});
```
## パフォーマンステストケース
### 負荷テスト
```typescript
describe('パフォーマンステスト', () => {
it('ログインAPI - 100同時接続テスト', async () => {
const promises = Array.from({ length: 100 }, () =>
request(app).post('/auth/login').send(validCredentials)
);
const startTime = Date.now();
const responses = await Promise.all(promises);
const endTime = Date.now();
// 全てのリクエストが成功
responses.forEach(response => {
expect(response.status).toBe(200);
});
// 応答時間が5秒以内
expect(endTime - startTime).toBeLessThan(5000);
});
it('データベース - 大量データ検索性能', async () => {
// 1000件のテストデータを作成
await createTestData(1000);
const startTime = Date.now();
const response = await request(app)
.get('/users')
.query({ limit: 100, offset: 0 });
const endTime = Date.now();
expect(response.status).toBe(200);
expect(endTime - startTime).toBeLessThan(1000); // 1秒以内
});
});
```
### セキュリティテスト
```typescript
describe('セキュリティテスト', () => {
it('SQLインジェクション対策', async () => {
const maliciousInput = "'; DROP TABLE users; --";
const response = await request(app)
.post('/auth/login')
.send({
email: maliciousInput,
password: 'password'
});
// システムが正常に動作し、データベースが破損していない
expect(response.status).toBe(400);
// ユーザーテーブルが依然として存在することを確認
const usersResponse = await request(app)
.get('/users')
.set('Authorization', 'Bearer ' + validToken);
expect(usersResponse.status).not.toBe(500);
});
it('XSS対策', async () => {
const xssPayload = '<script>alert("XSS")</script>';
const response = await request(app)
.post('/users')
.set('Authorization', 'Bearer ' + validToken)
.send({
name: xssPayload,
email: 'test@example.com'
});
// レスポンスでスクリプトがエスケープされている
expect(response.body.data.name).not.toContain('<script>');
expect(response.body.data.name).toContain('&lt;script&gt;');
});
});
```
## E2Eテストケース
### Playwright/Cypress テストシナリオ
```typescript
// ユーザーログインフロー E2Eテスト
describe('ユーザーログインフロー', () => {
it('正常なログインからダッシュボード表示まで', async () => {
await page.goto('/login');
// ログインフォーム入力
await page.fill('[data-testid="email-input"]', 'test@example.com');
await page.fill('[data-testid="password-input"]', 'password123');
await page.click('[data-testid="login-button"]');
// ダッシュボードへリダイレクト
await page.waitForURL('/dashboard');
// ユーザー情報表示確認
await expect(page.locator('[data-testid="user-name"]')).toContainText('テストユーザー');
// ログアウト機能確認
await page.click('[data-testid="logout-button"]');
await page.waitForURL('/login');
});
it('ログイン失敗時のエラー表示', async () => {
await page.goto('/login');
await page.fill('[data-testid="email-input"]', 'wrong@example.com');
await page.fill('[data-testid="password-input"]', 'wrongpassword');
await page.click('[data-testid="login-button"]');
// エラーメッセージ表示確認
await expect(page.locator('[data-testid="error-message"]'))
.toContainText('認証情報が正しくありません');
});
});
```
## テスト環境設定
### データベーステスト設定
```typescript
// テスト用データベース設定
beforeAll(async () => {
// テスト用データベース接続
await setupTestDatabase();
// マイグレーション実行
await runMigrations();
});
beforeEach(async () => {
// 各テスト前にデータをクリーンアップ
await cleanupDatabase();
// 基本テストデータ投入
await seedTestData();
});
afterAll(async () => {
// テスト用データベース切断
await teardownTestDatabase();
});
```
### モック設定
```typescript
// 外部サービスのモック
jest.mock('./email.service', () => ({
EmailService: jest.fn().mockImplementation(() => ({
sendEmail: jest.fn().mockResolvedValue(true)
}))
}));
// 環境変数のモック
process.env.JWT_SECRET = 'test-secret';
process.env.NODE_ENV = 'test';
```
## 不足テストの優先順位
### 高優先度（即座に実装推奨）
1. **E2Eテストスイート** - ユーザーフロー全体の動作保証
2. **API統合テスト** - バックエンドAPI全体のテスト
3. **セキュリティテスト** - 脆弱性対策の検証
### 中優先度（次のスプリントで実装）
1. **パフォーマンステスト** - 負荷・応答時間テスト
2. **UIコンポーネントテスト** - フロントエンド動作保証
3. **データベーステスト** - データ整合性テスト
### 低優先度（継続的改善として実装）
1. **ブラウザ互換性テスト** - 複数ブラウザでの動作確認
2. **アクセシビリティテスト** - a11y対応確認
3. **国際化テスト** - 多言語対応確認
```
### test-cases.md
```markdown
# {プロジェクト名} テストケース一覧（逆生成）
## テストケース概要
| ID | テスト名 | カテゴリ | 優先度 | 実装状況 | 推定工数 |
|----|----------|----------|--------|----------|----------|
| TC-001 | ログイン正常系 | API | 高 | ✅ | 2h |
| TC-002 | ログイン異常系 | API | 高 | ✅ | 3h |
| TC-003 | E2Eログインフロー | E2E | 高 | ❌ | 4h |
| TC-004 | パフォーマンス負荷テスト | パフォーマンス | 中 | ❌ | 6h |
## 詳細テストケース
### TC-001: ログインAPI正常系テスト
**テスト目的**: 有効な認証情報でのログイン機能を検証
**事前条件**:
- テストユーザーがデータベースに存在する
- パスワードが正しくハッシュ化されている
**テスト手順**:
1. POST /auth/login にリクエスト送信
2. 有効なemail, passwordを含むJSONを送信
3. レスポンスを確認
**期待結果**:
- HTTPステータス: 200
- success: true
- data.token: JWT形式のトークン
- data.user: ユーザー情報
**実装ファイル**: `auth.controller.spec.ts`
### TC-002: ログインAPI異常系テスト
**テスト目的**: 無効な認証情報での適切なエラーハンドリングを検証
**テストケース**:
1. 存在しないメールアドレス
2. 無効なパスワード
3. 不正なメール形式
4. 空文字・null値
5. SQLインジェクション攻撃
**期待結果**:
- 適切なHTTPステータスコード
- 統一されたエラーレスポンス形式
- セキュリティ脆弱性がない
**実装状況**: ✅ 部分的実装
```
## テストコード生成アルゴリズム
### 1. 静的解析によるテストケース抽出
```
1. 関数シグネチャ解析 → 引数・戻り値のテストケース
2. 条件分岐解析 → 分岐網羅テストケース
3. 例外処理解析 → 異常系テストケース
4. データベースアクセス解析 → データテストケース
```
### 2. 動的解析によるテスト生成
```
1. API呼び出しログ → 実際の使用パターンテスト
2. ユーザー操作ログ → E2Eテストシナリオ
3. パフォーマンスログ → 負荷テストシナリオ
```
### 3. テストカバレッジギャップ分析
```
1. 現在のカバレッジ測定
2. 未テスト行・分岐の特定
3. クリティカルパスの特定
4. リスクベース優先順位付け
```
## 実行コマンド例
```bash
# フル分析（全テストケース生成）
claude code rev-specs
# 特定のテストカテゴリのみ生成
claude code rev-specs --type unit
claude code rev-specs --type integration
claude code rev-specs --type e2e
# 特定のファイル/ディレクトリを対象
claude code rev-specs --path ./src/auth
# テストコードの実際の生成と出力
claude code rev-specs --generate-code
# カバレッジレポートと合わせて分析
claude code rev-specs --with-coverage
# 優先度フィルタリング
claude code rev-specs --priority high
```
## 実行後の確認
- 現在のテストカバレッジと不足部分の詳細レポート表示
- 生成されたテストケース数と推定実装工数を表示
- 優先順位付けされた実装推奨リストを提示
- テスト環境の設定要件と推奨ツールを提案
- CI/CD パイプラインへの統合案を提示

274
commands/rev-tasks.md Normal file
View File

@@ -0,0 +1,274 @@
---
description: 既存のコードベースを分析し、実装されている機能を特定してタスク一覧として整理します。実装済みの機能から逆算してタスクの構造、依存関係、実装詳細を抽出し、文書化します。
---
# rev-tasks
## 目的
既存のコードベースを分析し、実装されている機能を特定してタスク一覧として整理する。実装済みの機能から逆算してタスクの構造、依存関係、実装詳細を抽出し、文書化する。
## 前提条件
- 分析対象のコードベースが存在する
- `docs/reverse/` ディレクトリが存在する（なければ作成）
- TypeScript/JavaScript、Python、その他のコードを分析可能
## 実行内容
1. **コードベースの構造分析**
- ディレクトリ構造の把握
- 設定ファイルの確認（package.json、tsconfig.json、requirements.txt等）
- 依存関係の分析
2. **機能コンポーネントの特定**
- フロントエンドコンポーネント
- バックエンドサービス/コントローラー
- データベース関連（モデル、マイグレーション）
- ユーティリティ関数
- ミドルウェア
3. **API エンドポイントの抽出**
- REST API エンドポイント
- GraphQL リゾルバー
- WebSocket ハンドラー
- ルーティング定義
4. **データベース構造の分析**
- テーブル定義
- リレーションシップ
- マイグレーションファイル
- インデックス設定
5. **UI/UX実装の分析**
- 画面コンポーネント
- 状態管理の実装
- ルーティング
- スタイリング手法
6. **テスト実装の確認**
- 単体テストの存在
- 統合テストの存在
- E2Eテストの存在
- テストカバレッジ
7. **タスクの逆算と整理**
- 実装された機能をタスクとして分解
- タスクIDの自動割り当て
- 依存関係の推定
- 実装工数の推定
8. **ファイルの作成**
- `docs/reverse/{プロジェクト名}-discovered-tasks.md` として保存
- 発見されたタスクを構造化して文書化
## 出力フォーマット例
````markdown
# {プロジェクト名} 発見タスク一覧
## 概要
**分析日時**: {分析実行日時}
**対象コードベース**: {パス}
**発見タスク数**: {数}
**推定総工数**: {時間}
## コードベース構造
### プロジェクト情報
- **フレームワーク**: {使用フレームワーク}
- **言語**: {使用言語}
- **データベース**: {使用DB}
- **主要ライブラリ**: {主要な依存関係}
### ディレクトリ構造
```
{ディレクトリツリー}
```
## 発見されたタスク
### 基盤・設定タスク
#### DISCOVERED-001: プロジェクト初期設定
- [x] **タスク完了** (実装済み)
- **タスクタイプ**: DIRECT
- **実装ファイル**:
- `package.json`
- `tsconfig.json`
- `.env.example`
- **実装詳細**:
- {発見された設定内容}
- **推定工数**: {時間}
#### DISCOVERED-002: データベース設定
- [x] **タスク完了** (実装済み)
- **タスクタイプ**: DIRECT
- **実装ファイル**:
- `src/database/connection.ts`
- `migrations/001_initial.sql`
- **実装詳細**:
- {発見されたDB設定内容}
- **推定工数**: {時間}
### API実装タスク
#### DISCOVERED-101: ユーザー認証API
- [x] **タスク完了** (実装済み)
- **タスクタイプ**: TDD
- **実装ファイル**:
- `src/auth/auth.controller.ts`
- `src/auth/auth.service.ts`
- `src/auth/jwt.strategy.ts`
- **実装詳細**:
- ログイン/ログアウト機能
- JWT トークン発行
- 認証ミドルウェア
- **APIエンドポイント**:
- `POST /auth/login`
- `POST /auth/logout`
- `POST /auth/refresh`
- **テスト実装状況**:
- [x] 単体テスト: `auth.service.spec.ts`
- [x] 統合テスト: `auth.controller.spec.ts`
- [ ] E2Eテスト: 未実装
- **推定工数**: {時間}
### UI実装タスク
#### DISCOVERED-201: ログイン画面
- [x] **タスク完了** (実装済み)
- **タスクタイプ**: TDD
- **実装ファイル**:
- `src/components/Login/LoginForm.tsx`
- `src/components/Login/LoginForm.module.css`
- `src/hooks/useAuth.ts`
- **実装詳細**:
- ログインフォーム
- バリデーション機能
- エラーハンドリング
- **UI/UX実装状況**:
- [x] レスポンシブデザイン
- [x] ローディング状態
- [x] エラー表示
- [ ] アクセシビリティ: 部分的実装
- **テスト実装状況**:
- [x] コンポーネントテスト: `LoginForm.test.tsx`
- [ ] E2Eテスト: 未実装
- **推定工数**: {時間}
## 未実装・改善推奨事項
### 不足しているテスト
- [ ] **E2Eテストスイート**: 主要ユーザーフローのテスト
- [ ] **パフォーマンステスト**: API応答時間テスト
- [ ] **セキュリティテスト**: 認証・認可テスト
### コード品質改善
- [ ] **TypeScript型安全性**: 一部でany型の使用
- [ ] **エラーハンドリング**: 統一的なエラー処理
- [ ] **ログ出力**: 構造化ログの実装
### ドキュメント不足
- [ ] **API仕様書**: OpenAPI/Swagger未実装
- [ ] **開発者ガイド**: セットアップ手順書
- [ ] **デプロイ手順書**: 本番環境構築手順
## 依存関係マップ
```mermaid
graph TD
A[DISCOVERED-001: プロジェクト初期設定] --> B[DISCOVERED-002: データベース設定]
B --> C[DISCOVERED-101: ユーザー認証API]
C --> D[DISCOVERED-201: ログイン画面]
D --> E[未実装: E2Eテスト]
F[未実装: API仕様書] --> G[未実装: 開発者ガイド]
```
## 実装パターン分析
### アーキテクチャパターン
- **実装パターン**: {発見されたパターン}
- **状態管理**: {使用されている状態管理}
- **認証方式**: {実装されている認証方式}
### コーディングスタイル
- **命名規則**: {発見された命名規則}
- **ファイル構成**: {ファイル構成パターン}
- **エラーハンドリング**: {エラー処理パターン}
## 技術的負債・改善点
### パフォーマンス
- {発見されたパフォーマンス課題}
### セキュリティ
- {発見されたセキュリティ課題}
### 保守性
- {発見された保守性課題}
## 推奨次ステップ
1. **不足テストの実装** - 特にE2Eテストスイート
2. **ドキュメント整備** - API仕様書とセットアップガイド
3. **コード品質改善** - TypeScript型安全性とエラーハンドリング
4. **セキュリティ強化** - 認証・認可の詳細レビュー
````
## 分析対象ファイルの自動検出
### フロントエンド
- React: `*.tsx`, `*.jsx`, `*.ts`, `*.js`
- Vue: `*.vue`, `*.ts`, `*.js`
- Angular: `*.component.ts`, `*.service.ts`, `*.module.ts`
### バックエンド
- Node.js: `*.ts`, `*.js` (Express, NestJS等)
- Python: `*.py` (Django, FastAPI等)
- Java: `*.java` (Spring Boot等)
### データベース
- SQL: `*.sql`, `migrations/*`
- ORM: モデルファイル、設定ファイル
### 設定ファイル
- `package.json`, `tsconfig.json`, `webpack.config.js`
- `requirements.txt`, `Pipfile`, `pyproject.toml`
- `pom.xml`, `build.gradle`
## 実行コマンド例
```bash
# カレントディレクトリを分析
claude code rev-tasks
# 特定ディレクトリを分析
claude code rev-tasks --path ./backend
# 特定の技術スタックに絞って分析
claude code rev-tasks --tech react,nodejs
# 詳細分析（テストカバレッジ等も含む）
claude code rev-tasks --detailed
# 出力形式指定
claude code rev-tasks --format json
```
## 実行後の確認
- 発見されたタスク数と推定工数を表示
- 実装済み/未実装の機能一覧を表示
- 技術的負債・改善推奨事項をサマリー表示
- 次のリバースエンジニアリングステップ（設計書生成等）を提案

83
commands/start-server.md Normal file
View File

@@ -0,0 +1,83 @@
---
description: 開発環境のサーバを起動・管理するコマンドです。
---
# 開発サーバ起動・管理
開発環境のサーバを起動・管理するコマンドです。
## サーバ起動確認・管理
開発開始前にサーバの状態を確認し、必要に応じて起動します：
```bash
# 既存のViteサーバ確認
ps aux | grep -E "vite.*--port 3000" | grep -v grep
# サーバが起動していない場合は新規起動
if ! ps aux | grep -E "vite.*--port 3000" | grep -v grep > /dev/null; then
echo "サーバが起動していません。開発サーバを起動します..."
npm run dev &
echo "サーバ起動中... 5秒待機します"
sleep 5
else
echo "既存のサーバが見つかりました。そのまま利用します。"
ps aux | grep -E "vite.*--port 3000" | grep -v grep | awk '{print "PID: " $2 " - Viteサーバが既に起動中"}'
fi
# サーバ動作確認
echo "サーバ動作確認中..."
curl -s http://localhost:3000 > /dev/null && echo "✅ サーバは正常に動作しています" || echo "⚠️ サーバに接続できません"
```
## サーバ管理コマンド
### サーバ状態確認
```bash
# 現在動作中のサーバプロセス確認
ps aux | grep -E "vite.*--port 3000" | grep -v grep
# ポート使用状況確認
lsof -i :3000
```
### サーバ停止
```bash
# Viteサーバの停止
pkill -f "vite.*--port 3000"
# 強制停止（上記で停止しない場合）
ps aux | grep -E "vite.*--port 3000" | grep -v grep | awk '{print $2}' | xargs kill -9
```
### サーバ再起動
```bash
# サーバ停止
pkill -f "vite.*--port 3000"
# 少し待機
sleep 2
# サーバ再起動
npm run dev &
# 起動確認
sleep 5
curl -s http://localhost:3000 > /dev/null && echo "✅ サーバは正常に動作しています" || echo "⚠️ サーバに接続できません"
```
## 使用場面
- TDD開発開始前の環境準備
- サーバが停止している場合の復旧
- サーバの状態確認が必要な場合
- 開発環境のセットアップ時
## 注意事項
- ポート3000が他のプロセスに使用されている場合は、該当プロセスを終了してください
- サーバ起動後は、ブラウザで http://localhost:3000 にアクセスして動作確認できます
- バックグラウンドで起動したサーバは、作業終了時に適切に停止することを推奨します

158
commands/tdd-cycle-full.sh Executable file
View File

@@ -0,0 +1,158 @@
#!/bin/bash
# TDD フルサイクル実行スクリプト
# Usage: ./tdd-cycle-full.sh <test_case_name>
# 開始時間記録
START_TIME=$(date +%s)
if [ $# -ne 1 ]; then
echo "Usage: $0 <test_case_name>"
exit 1
fi
TEST_CASE_NAME=$1
# カラー定義
RED='\033[0;31m'
GREEN='\033[0;32m'
BLUE='\033[0;34m'
YELLOW='\033[1;33m'
NC='\033[0m' # No Color
# Claude コマンド共通設定
ALLOWED_TOOLS="Write,Edit,Bash(npm:*),Bash(node:*)"
DISALLOWED_TOOLS="Bash(git *)"
VERIFY_ALLOWED_TOOLS="Write,Edit,Bash(npm:*),Bash(node:*),Bash(git status),Bash(git diff)"
VERIFY_DISALLOWED_TOOLS="Bash(git add),Bash(git commit),Bash(git push)"
# TDDサイクル実行関数
run_tdd_cycle() {
local test_case=$1
echo "🔴 RED フェーズ開始..."
if ! claude -p "/tsumiki:tdd-red $test_case 不足テストの追加実装" --allowedTools "$ALLOWED_TOOLS" --disallowedTools "$DISALLOWED_TOOLS"; then
echo -e "${RED}❌ RED フェーズ失敗${NC}"
exit 1
fi
echo -e "${GREEN}✅ RED フェーズ完了${NC}"
echo "🟢 GREEN フェーズ開始..."
if ! claude -p "/tsumiki:tdd-green $test_case" --allowedTools "$ALLOWED_TOOLS" --disallowedTools "$DISALLOWED_TOOLS"; then
echo -e "${RED}❌ GREEN フェーズ失敗${NC}"
exit 1
fi
echo -e "${GREEN}✅ GREEN フェーズ完了${NC}"
echo "🔵 REFACTOR フェーズ開始..."
if ! claude -p "/tsumiki:tdd-refactor $test_case" --allowedTools "$ALLOWED_TOOLS" --disallowedTools "$DISALLOWED_TOOLS"; then
echo -e "${RED}❌ REFACTOR フェーズ失敗${NC}"
exit 1
fi
echo -e "${GREEN}✅ REFACTOR フェーズ完了${NC}"
echo "🔍 VERIFY COMPLETE フェーズ開始..."
local verify_result
verify_result=$(claude -p "/tsumiki:tdd-verify-complete $test_case" --allowedTools "$VERIFY_ALLOWED_TOOLS" --disallowedTools "$VERIFY_DISALLOWED_TOOLS" 2>&1)
local verify_exit_code=$?
if [ $verify_exit_code -ne 0 ]; then
echo -e "${RED}❌ VERIFY COMPLETE フェーズ失敗${NC}"
exit 1
fi
echo -e "${GREEN}✅ VERIFY COMPLETE フェーズ完了${NC}"
echo -e "${verify_result}
# 結果の判定
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
echo -e "${YELLOW}🔄 TDDサイクル継続${NC}: 品質基準に満たない項目が見つかりました。RED フェーズに戻ります..."
return 1
else
echo -e "${YELLOW}⚠️ 判定結果が不明確です${NC}"
echo "--- VERIFY COMPLETE フェーズの出力 ---"
echo "$verify_result"
echo "--- 出力終了 ---"
echo ""
echo -e "${BLUE}以下から選択してください:${NC}"
echo "1) 完了として扱う（TDDサイクルを終了）"
echo "2) RED フェーズから継続する"
echo "3) スクリプトを終了する"
echo ""
while true; do
read -p "選択 (1/2/3): " choice
case $choice in
1)
echo -e "${GREEN}🎉 TDDサイクル完了${NC}: ユーザー判断により完了とします"
return 0
;;
2)
echo -e "${YELLOW}🔄 TDDサイクル継続${NC}: ユーザー判断により RED フェーズに戻ります"
return 1
;;
3)
echo -e "${BLUE}👋 スクリプトを終了します${NC}"
exit 0
;;
*)
echo "無効な選択です。1, 2, または 3 を入力してください。"
;;
esac
done
fi
}
# 完了時間表示関数
show_completion_time() {
local exit_code=$1
local end_time=$(date +%s)
local duration=$((end_time - START_TIME))
local hours=$((duration / 3600))
local minutes=$(((duration % 3600) / 60))
local seconds=$((duration % 60))
printf "⏱️ 実行時間: "
if [ $hours -gt 0 ]; then
printf "%d時間%d分%d秒\n" $hours $minutes $seconds
elif [ $minutes -gt 0 ]; then
printf "%d分%d秒\n" $minutes $seconds
else
printf "%d秒\n" $seconds
fi
printf "🕐 終了時刻: %s\n" "$(date +'%Y-%m-%d %H:%M:%S')"
if [ $exit_code -eq 0 ]; then
echo -e "${GREEN}✅ 正常終了${NC}"
else
echo -e "${RED}❌ エラー終了${NC}"
fi
}
# trap設定（エラー終了時にも時間表示）
trap 'show_completion_time $?' EXIT
# メインループ
echo "TDD フルサイクル実行開始: $TEST_CASE_NAME"
max_cycles=5
cycle_count=0
while [ $cycle_count -lt $max_cycles ]; do
cycle_count=$((cycle_count + 1))
echo -e "${BLUE}=== サイクル $cycle_count 開始 ===${NC}"
if run_tdd_cycle "$TEST_CASE_NAME"; then
echo -e "${GREEN}🎉 全体完了: TDDサイクルが正常に完了しました${NC}"
exit 0
fi
echo -e "${YELLOW}サイクル $cycle_count 完了、次のサイクルに進みます...${NC}"
echo ""
done
echo -e "${RED}❌ 最大サイクル数($max_cycles)に達しました。手動で確認してください。${NC}"
exit 1

243
commands/tdd-green.md Normal file
View File

@@ -0,0 +1,243 @@
---
description: TDDのGreenフェーズを実行します。失敗しているテストケースを通すための実装を行い、テストが成功することを確認します。
---
# TDD Greenフェーズ（実装）
TDDのGreenフェーズを実行します。
## 事前準備
開発コンテキストの準備を行います：
1. **追加ルールの読み込み**
- `AGENTS.md` ファイルが存在する場合は読み込み
- `docs/rule` ディレクトリが存在する場合は読み込み
- `docs/rule/tdd` ディレクトリが存在する場合は読み込み
- `docs/rule/tdd/green` ディレクトリが存在する場合は読み込み
- 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用
2. **@agent-symbol-searcher で実装関連情報を検索し、見つかったファイルを読み込み**
- 既存の類似機能やユーティリティ関数を検索し、該当ファイルをReadツールで読み込み
- 実装パターンやアーキテクチャガイドラインを特定し、設計文書をReadツールで読み込み
- 依存関係やインポートパスを確認し、関連ファイルをReadツールで読み込み
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フェーズ（実装）の作業を開始します。
**テスト実行時はTaskツールを利用する**
## 信頼性レベル指示
実装コード作成時には、各実装内容について元の資料との照合状況を以下の信号でコメントしてください：
- 🔵 **青信号**: 元の資料を参考にしてほぼ推測していない場合
- 🟡 **黄信号**: 元の資料から妥当な推測の場合
- 🔴 **赤信号**: 元の資料にない推測の場合
## 目標
Redフェーズで作成したテストを通すための**実装**を行ってください。
## 実装の原則
- **テストが確実に通ること最優先**
- コードの美しさは二の次（次のRefactorフェーズで改善）
- 「とりあえず動く」レベルでOK
- 複雑なロジックは後回し、シンプルな実装を心がける
- テストがなかなか通らないときは、Taskツールを使用して失敗原因を調べてから修正の計画を立てて実装する
- 既存のテストがエラーになった場合は仕様を元に適切に修正する
- **モック使用の制限**: テストコード以外でモックを記述しない（実装コードは実際のロジックを書く）
- **ファイルサイズ管理**: 実装ファイルが800行を超えた時点でファイル分割を検討する
- NEVER: 必要なテストのスキップ禁止
- NEVER: 必要なテストの削除禁止
- NEVER: 実装コード内でのモック・スタブの記述禁止
- NEVER: 実装コード内でDBに代わるインメモリーストレージの利用禁止
- NEVER: 実装コード内でDB操作の省略禁止
## 実装時の日本語コメント要件
実装コードには以下の日本語コメントを必ず含めてください：
### 関数・メソッドレベルのコメント
```javascript
/**
* 【機能概要】: [この関数が何をするかを日本語で説明]
* 【実装方針】: [なぜこのような実装方法を選んだかを説明]
* 【テスト対応】: [どのテストケースを通すための実装かを明記]
* 🔵🟡🔴 信頼性レベル: [この実装が元資料のどの程度に基づいているか]
* @param {type} paramName - [パラメータの説明]
* @returns {type} - [戻り値の説明]
*/
function {{function_name}}(paramName) {
// 【実装内容】: [実装している処理の詳細説明]
}
```
### 処理ブロックレベルのコメント
```javascript
function processData(input) {
// 【入力値検証】: [入力値の妥当性をチェックする理由と方法] 🔵🟡🔴
if (!input) {
throw new Error('入力値が不正です'); // 【エラー処理】: [なぜこのエラーが必要かを説明] 🔵🟡🔴
}
// 【データ処理開始】: [メイン処理の開始を明示] 🔵🟡🔴
// 【処理方針】: [この処理がテストを通すためにどう貢献するかを説明] 🔵🟡🔴
const result = {
// 【結果構造】: [戻り値の構造とその理由を説明]
validData: [],
invalidData: [],
errors: [],
};
// 【結果返却】: [処理結果を返す理由と内容の説明]
return result;
}
```
### 変数・定数のコメント
```javascript
// 【定数定義】: [この定数が必要な理由と使用目的]
const MAX_FILE_SIZE = 1024 * 1024; // 【制限値】: ファイルサイズの上限（1MB）を設定
// 【変数初期化】: [この変数がテスト通過のためになぜ必要かを説明]
let processedCount = 0; // 【カウンタ】: 処理済みファイル数を追跡するためのカウンタ
```
### エラーハンドリングのコメント
```javascript
try {
// 【実処理実行】: [実際の処理を実行する部分の説明]
const data = processFile(filePath);
} catch (error) {
// 【エラー捕捉】: [エラーが発生した場合の対処方針]
// 【テスト要件対応】: [テストで期待されるエラーハンドリングを満たすための処理]
return {
success: false,
error: error.message, // 【エラー情報】: テストで検証されるエラーメッセージを適切に返却
};
}
```
## 実装例
```javascript
/**
* 【機能概要】: JSONファイルパスを検証し、有効/無効なパスを分類する
* 【実装方針】: テストケースを通すために最低限必要な機能のみを実装
* 【テスト対応】: tdd-red フェーズで作成されたテストケースを通すための実装
*/
function {{function_name}}(input) {
// 【入力値検証】: 不正な入力値を早期に検出してエラーを防ぐ
if (!input) {
// 【エラー処理】: テストで期待されるエラーケースに対応
throw new Error('入力値が必要です');
}
// 【最小限実装】: テストを通すための最もシンプルな実装
// 【ハードコーディング許可】: リファクタ段階で改善予定のため、現段階では固定値でOK
return {{simple_return_value}};
}
```
## 段階的実装のガイドライン
1. **まず1つのテストケースだけ通す**
- 【実装戦略】: 複数テストの同時対応は複雑化を招くため避ける
- 【品質確保】: 1つずつ確実に実装することで品質を担保
2. **最も簡単な方法で実装**
- 【シンプル実装】: 複雑なアルゴリズムは後のリファクタで追加
- 【可読性重視】: 現段階では理解しやすさを最優先
3. **ファイルサイズを意識した実装**
- 【800行制限】: 実装ファイルが800行を超えた時点で分割を検討
- 【モジュール設計】: 機能単位でファイルを適切に分離
- 【関数分割】: 長大な関数は小さな単位に分割して実装
- 【責任境界】: 各ファイルの責任範囲を明確にして実装
- 【分割戦略】: 機能・レイヤー・ドメインでファイルを分離
4. **コード品質基準の考慮**
- 【静的解析対応】: lintやtypecheckでエラーが出ない実装を心がける
- 【フォーマット統一】: プロジェクトの既存フォーマットに合わせた実装
- 【命名規則遵守】: プロジェクトの命名規則に従った実装
5. **他のテストケースは後回し**
- 【段階的開発】: TDDの原則に従い、1ステップずつ進める
- 【影響範囲限定】: 変更の影響を最小限に抑える
6. **エラーハンドリングも最小限**
- 【必要最小限】: テストで要求される部分のみ実装
- 【将来拡張可能】: リファクタ段階で詳細なエラー処理を追加予定
7. **モック使用の制限**
- 【実装コード制限】: 実装コード内でモック・スタブを使用しない
- 【テストコード限定】: モックはテストコード内でのみ使用
- 【実際のロジック実装】: 実装コードは実際の処理を記述する
- 【依存関係注入】: 必要に応じて依存性注入パターンで実装
## 提供してください
1. **実装コード**: テストを通すコード（必須の日本語コメント付き）
2. **テスト実行結果**: Taskツールを使用して実際にテストが通ることの確認
3. **実装の説明**: どのような考えで実装したか（日本語コメントとの対応関係）
4. **課題の特定**: 現在の実装の問題点（リファクタ対象の明確化）
5. **ファイルサイズチェック**: 実装ファイルの行数確認（800行超過時の分割計画）
6. **モック使用確認**: 実装コードにモック・スタブが含まれていないことの確認
実装完了後、以下を実行してください：
1. **メモファイル更新**: `docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md` ファイルのGreenフェーズセクションを更新
- 実装方針、実装コード、テスト結果、課題・改善点を記録
- 次のRefactorフェーズで参照できるよう詳細に記録
2. 実装コードと設計内容を `docs/implements/{要件名}/{{task_id}}/{feature_name}-green-phase.md` に保存（既存ファイルがある場合は追記）
3. TODOステータスを更新（Greenフェーズ完了をマーク）
4. **自動遷移判定**: 以下の条件を満たす場合は自動で `/tdd-refactor` を実行
- Taskツールを使用して全てのテストが成功していることを確認済み
- 実装がシンプルで理解しやすい
- 明らかなリファクタリング箇所がある
- 機能的な問題がない
5. **手動確認**: 自動遷移条件を満たさない場合は以下を提供してください：
- 「Taskツールを使用してテストが通ったことを確認しました。」
- 「現在の実装: [簡潔な説明]」
- 「実装に含めた日本語コメント: [コメントの目的と内容]」
- 「リファクタリングの候補: [改善すべき点]」
- 「次のRefactorフェーズに進んでよろしいですか？」
## 品質判定基準
```
✅ 高品質:
- テスト結果: Taskツールによる実行で全て成功
- 実装品質: シンプルかつ動作する
- リファクタ箇所: 明確に特定可能
- 機能的問題: なし
- コンパイルエラー: なし
- ファイルサイズ: 800行以下または分割計画が明確
- モック使用: 実装コードにモック・スタブが含まれていない
⚠️ 要改善:
- テストの一部が失敗（Taskツールで検出）
- 実装が複雑すぎる
- リファクタ方針が不明
- 機能に懸念がある
- コンパイルエラーが存在
- ファイルサイズが800行を超過し分割計画が不明
- 実装コードにモック・スタブが含まれている
```
## TODO更新パターン
```
- 現在のTODO「Greenフェーズ（最小実装）」を「completed」にマーク
- 最小実装フェーズの完了をTODO内容に反映
- 品質判定結果をTODO内容に記録
- 次のフェーズ「Refactorフェーズ（品質改善）」をTODOに追加
```
次のステップ: `/tdd-refactor` でコードの品質を改善します。

120
commands/tdd-load-context.md Normal file
View File

@@ -0,0 +1,120 @@
---
description: TDD関連ファイル読み込み・コンテキスト準備を行います (非推奨)
---
# TDD関連ファイル読み込み・コンテキスト準備 (非推奨)
**注意**: このコマンドは非推奨です。他のTDDコマンドでは@agent-symbol-searcherとReadツールを直接使用してコンテキストを準備します。
以下は参考情報として保持しています。
## 実行タスク
以下の@agent-symbol-searcherとTaskツールによる並列読み込み・検索を実行します：
### 0. **@agent-symbol-searcher で関連情報を検索**
- 対象機能に関連する既存シンボル・関数・クラスを検索
- 類似機能の実装パターンやアーキテクチャを特定
- TDD関連のツール・フレームワークの使用方法を確認
```
1. 【読み込み】TDDメモファイルの確認
- Readツール: `docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md`
- 既存の開発履歴、フェーズ情報、検証結果を把握
2. 【読み込み】要件定義文書の確認
- Readツール: `docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md`
- 機能仕様、入出力、制約条件を把握
3. 【読み込み】テストケース定義の確認
- Readツール: `docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md`
- 予定テストケース、分類、期待値を把握
4. 【探索のみ】プロジェクト設計文書の特定
- Globツール: `docs/spec/{feature_name}-requirements.md` の存在確認
- Globツール: `docs/design/{feature_name}/` ディレクトリ内ファイルの特定
- 見つかったファイルパスを記録（読み込みは実行せず）
5. 【探索のみ】プロジェクト構造・ライブラリファイルの特定
- Globツール: `package.json` の存在確認
- Globツール: 既存テストファイル構造の把握（`**/*test*.js`, `**/*spec*.js`等）
- Grepツール: 類似機能の実装パターン調査（関連キーワード検索）
- 見つかったファイルパスを記録（読み込みは実行せず）
6. 【探索のみ】タスク管理文書の特定
- Globツール: `docs/tasks/{要件名}-tasks.md` の存在確認
- 見つかったファイルパスを記録（読み込みは実行せず）
```
## 読み込み結果の整理
読み込み・探索完了後、以下の形式で情報を整理します：
### 📋 開発コンテキスト情報
```markdown
## TDD開発コンテキスト
### 🎯 現在のフェーズ・状況
- **対象機能**: {feature_name}
- **現在のTDDフェーズ**: [Requirements/TestCases/Red/Green/Refactor/Verify]
- **前回の完了フェーズ**: [前回完了したフェーズ]
- **今回の実行予定**: [実行すべき次のステップ]
### 📄 要件・仕様情報
- **機能概要**: [要件定義書から抽出した機能の概要]
- **入力仕様**: [入力パラメータの型・制約・範囲]
- **出力仕様**: [出力形式・構造・期待値]
- **制約条件**: [パフォーマンス・セキュリティ・技術制約]
- **参照EARS要件**: [REQ-XXX, NFR-XXX等の要件ID]
### 🔧 技術・実装情報
- **使用言語**: [JavaScript/TypeScript等]
- **テストフレームワーク**: [Jest/Mocha等]
- **関連ファイル**: [探索で見つかった関連ファイルパス一覧]
- **設計文書パス**: [見つかった設計文書のパス一覧]
- **類似実装パス**: [参考にできる既存実装のファイルパス]
### 📈 進捗・品質情報
- **全体タスク進捗**: [完了数]/[総数] ([%])
- **前回の検証結果**: [合格/不合格/未実施]
- **品質課題**: [セキュリティ・パフォーマンス課題]
- **改善要求事項**: [前回記録された改善点]
### ⚠️ 注意事項・制約
- **技術的制約**: [アーキテクチャ・互換性制約]
- **実装時の注意点**: [前回記録された重要な注意事項]
- **未解決課題**: [継続対応が必要な課題]
```
## 信頼性レベル判定
読み込んだ各情報について信頼性レベルを判定：
- 🔵 **青信号**: ファイルが存在し、詳細な情報が利用可能
- 🟡 **黄信号**: ファイルが存在するが情報が部分的
- 🔴 **赤信号**: ファイルが存在しない、または推測が必要
## 使用方法
各TDDコマンドの冒頭で以下のように使用：
```markdown
## 事前準備
開発コンテキストの準備を行います：
**Taskツール実行**: `/tsumiki:tdd-load-context` でTDD関連ファイルの読み込み・探索とコンテキスト準備を実行
読み込み完了後、準備されたコンテキスト情報を基に{現在のフェーズ}の作業を開始します。
```
## 効果
- **効率化**: メモ・要件・テストケースは読み込み、その他は探索のみで時間短縮
- **一貫性**: 全TDDフェーズで統一されたコンテキスト準備
- **品質向上**: 必要情報の読み込み漏れ防止
- **保守性**: ファイル読み込み・探索ロジックの一元管理
- **軽量化**: 関連ファイルは特定のみで、必要に応じて個別に読み込み可能
このタスクにより、@agent-symbol-searcherでの検索結果と既存TDDファイルの情報を組み合わせ、TDD開発の各フェーズで必要な情報を効率的に準備できます。

512
commands/tdd-red.md Normal file
View File

@@ -0,0 +1,512 @@
---
description: TDDのRedフェーズを実行します。失敗するテストケースを作成し、実装すべき機能を明確に定義します。
---
# TDD Redフェーズ（失敗するテストを書く）
TDDのRedフェーズを実行します。
## 事前準備
開発コンテキストの準備を行います：
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ツールで読み込み
- **E2Eテスト設定確認**: playwright.config.js、cypress.config.js等の設定ファイルをReadツールで読み込み
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フェーズ（失敗テスト作成）の作業を開始します。
## 対象テストケース
**【対象テストケース】**: {{test_case_name}}
## テストケース追加目標数
**テストケース追加目標数**: 10以上（利用可能なテストケースが10未満の場合は全て追加）
未実装のテストケースから10個以上のテストケースを選択して実装してください。利用可能なテストケースが10個未満の場合は、利用可能な全てのテストケースを実装対象とします。
既にテストケースが実装済みの場合はテストケース定義に書かれているテストケースからテストを追加します。
要件網羅率と機能網羅率を高めるテストケースを追加してください
NEVER テストケースの最大行数を500行を目標に分割してください
## 信頼性レベル指示
テストコード作成時には、各テストケースの内容について元の資料との照合状況を以下の信号でコメントしてください：
- 🔵 **青信号**: 元の資料を参考にしてほぼ推測していない場合
- 🟡 **黄信号**: 元の資料から妥当な推測の場合
- 🔴 **赤信号**: 元の資料にない推測の場合
## 要件
- **使用言語/フレームワーク**: 読み込んだ技術スタック定義に基づく
- テストは必ず失敗する状態で作成
- テスト名は分かりやすく日本語で記述
- アサーション（期待値の検証）を明確に記述
- まだ実装されていない関数・メソッドを呼び出す形で作成
## 🎯 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 エンドポイント
- データベース操作
- ユーティリティ関数
## テストコード作成指針
### E2Eテスト重視の構造
- **Scenario-Given-When-Then パターン**を採用
- **シナリオ定義**: どのようなユーザージャーニーをテストするか
- **初期状態設定（Given）**: ページアクセス、ログイン状態等
- **ユーザー操作実行（When）**: クリック、入力、ナビゲーション等
- **結果確認（Then）**: 画面表示、状態変化、ページ遷移等
### 単体・統合テスト用の構造
- **Given-When-Then パターン**を使用
- テストデータの準備（Given）
- 実際の処理の実行（When）
- 結果の検証（Then）
## 日本語コメント必須要件
テストコードには以下の日本語コメントを必ず含めてください：
### テストケース開始時のコメント
```javascript
describe('{{feature_name}}', () => {
test('{{test_case_name}}', () => {
// 【テスト目的】: [このテストで何を確認するかを日本語で明記]
// 【テスト内容】: [具体的にどのような処理をテストするかを説明]
// 【期待される動作】: [正常に動作した場合の結果を説明]
// 🔵🟡🔴 信頼性レベル: [このテストの内容が元資料のどの程度に基づいているか]
// 【テストデータ準備】: [なぜこのデータを用意するかの理由]
// 【初期条件設定】: [テスト実行前の状態を説明]
const input = {{test_input}};
// 【実際の処理実行】: [どの機能/メソッドを呼び出すかを説明]
// 【処理内容】: [実行される処理の内容を日本語で説明]
const result = {{function_name}}(input);
// 【結果検証】: [何を検証するかを具体的に説明]
// 【期待値確認】: [期待される結果とその理由を説明]
expect(result).toBe({{expected_output}}); // 【確認内容】: [この検証で確認している具体的な項目] 🔵🟡🔴
});
});
```
### セットアップ・クリーンアップのコメント（必要に応じて）
```javascript
beforeEach(() => {
// 【テスト前準備】: [各テスト実行前に行う準備作業の説明]
// 【環境初期化】: [テスト環境をクリーンな状態にする理由と方法]
});
afterEach(() => {
// 【テスト後処理】: [各テスト実行後に行うクリーンアップ作業の説明]
// 【状態復元】: [次のテストに影響しないよう状態を復元する理由]
});
```
### 各expectステートメントのコメント
各expectステートメントには必ず日本語コメントを付けてください：
```javascript
expect(result.property).toBe(expectedValue); // 【確認内容】: [この検証で確認している具体的な項目と理由]
expect(result.array).toHaveLength(3); // 【確認内容】: [配列の長さが期待値と一致することを確認する理由]
expect(result.errors).toContain('error message'); // 【確認内容】: [特定のエラーメッセージが含まれることを確認する理由]
```
## 作成するテストコードの例
### 単体テスト・統合テストの例
```javascript
// テストファイル: {{test_file_name}}
describe('{{feature_name}}', () => {
beforeEach(() => {
// 【テスト前準備】: 各テスト実行前にテスト環境を初期化し、一貫したテスト条件を保証
// 【環境初期化】: 前のテストの影響を受けないよう、ファイルシステムの状態をクリーンにリセット
});
afterEach(() => {
// 【テスト後処理】: テスト実行後に作成された一時ファイルやディレクトリを削除
// 【状態復元】: 次のテストに影響しないよう、システムを元の状態に戻す
});
test('{{test_case_name}}', () => {
// 【テスト目的】: {{test_purpose}}
// 【テスト内容】: {{test_description}}
// 【期待される動作】: {{expected_behavior}}
// 🔵🟡🔴 信頼性レベル: [このテストの内容が元資料のどの程度に基づいているか]
// 【テストデータ準備】: {{test_data_reason}}
// 【初期条件設定】: {{initial_condition}}
const input = {{test_input}};
// 【実際の処理実行】: {{function_description}}
// 【処理内容】: {{process_description}}
const result = {{function_name}}(input);
// 【結果検証】: {{verification_description}}
// 【期待値確認】: {{expected_result_reason}}
expect(result).toBe({{expected_output}}); // 【確認内容】: {{specific_verification_point}}
});
});
```
### 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. **テストコード**: 実行可能な形式で、必須の日本語コメント付き
2. **テスト実行コマンド**: どのように実行するか
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フェーズの内容を作成または追記
- 既存のメモファイルがある場合は、Redフェーズセクションを更新
- メモファイルが存在しない場合は新規作成
2. テストコードの設計内容を `docs/implements/{要件名}/{{task_id}}/{feature_name}-red-phase.md` に保存（既存ファイルがある場合は追記）
3. TODOステータスを更新（Redフェーズ完了をマーク）
4. **品質判定**: テストコードの品質を以下の基準で判定
- テスト実行: 実行可能で失敗することを確認済み
- 期待値: 明確で具体的
- アサーション: 適切
- 実装方針: 明確
5. **次のステップ表示**: 判定結果に関わらず、次のお勧めコマンドを表示
- 「次のお勧めステップ: `/tsumiki:tdd-green` でGreenフェーズ（最小実装）を開始します。」
## TDDメモファイル形式
`docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md` ファイルの形式：
```markdown
# TDD開発メモ: {feature_name}
## 概要
- 機能名: [機能名]
- 開発開始: [日時]
- 現在のフェーズ: [Red/Green/Refactor]
## 関連ファイル
- 元タスクファイル: `docs/tasks/{taskファイルのパス}.md`
- 要件定義: `docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md`
- テストケース定義: `docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md`
- 実装ファイル: `[実装ファイルのパス]`
- テストファイル: `[テストファイルのパス]`
## Redフェーズ（失敗するテスト作成）
### 作成日時
[日時]
### テストケース
[作成したテストケースの概要]
### テストコード
[実際のテストコード]
### 期待される失敗
[どのような失敗が期待されるか]
### 次のフェーズへの要求事項
[Greenフェーズで実装すべき内容]
## Greenフェーズ（最小実装）
### 実装日時
[日時]
### 実装方針
[最小実装の方針]
### 実装コード
[実際の実装コード]
### テスト結果
[テストが通った結果]
### 課題・改善点
[Refactorフェーズで改善すべき点]
## Refactorフェーズ（品質改善）
### リファクタ日時
[日時]
### 改善内容
[具体的な改善内容]
### セキュリティレビュー
[セキュリティ面での確認結果]
### パフォーマンスレビュー
[パフォーマンス面での確認結果]
### 最終コード
[リファクタ後のコード]
### 品質評価
[最終的な品質評価]
```
## 品質判定基準
```
✅ 高品質:
- テスト実行: 成功（失敗することを確認）
- 期待値: 明確で具体的
- アサーション: 適切
- 実装方針: 明確
⚠️ 要改善:
- テストが実行できない
- 期待値が曖昧
- 実装アプローチが不明
- 複雑なテストケース
```
## TODO更新パターン
```
- 現在のTODO「Redフェーズ（失敗テスト作成）」を「completed」にマーク
- 失敗テスト作成フェーズの完了をTODO内容に反映
- 品質判定結果をTODO内容に記録
- 次のフェーズ「Greenフェーズ（最小実装）」をTODOに追加
```
次のステップ: `/tsumiki:tdd-green` でテストを通すための最小限の実装を行います。

315
commands/tdd-refactor.md Normal file
View File

@@ -0,0 +1,315 @@
---
description: TDDのRefactorフェーズを実行します。テストを通す実装が完了した後、コード品質の改善とリファクタリングを行います。
---
# TDD Refactorフェーズ（コード改善）
TDDのRefactorフェーズを実行します。
## 事前準備
開発コンテキストの準備を行います：
1. **追加ルールの読み込み**
- `AGENTS.md` ファイルが存在する場合は読み込み
- `docs/rule` ディレクトリが存在する場合は読み込み
- `docs/rule/tdd` ディレクトリが存在する場合は読み込み
- `docs/rule/tdd/refactor` ディレクトリが存在する場合は読み込み
- 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用
2. **@agent-symbol-searcher でリファクタリング関連情報を検索し、見つかったファイルを読み込み**
- 既存のコードスタイルやベストプラクティスを検索し、スタイルガイドをReadツールで読み込み
- プロジェクト全体のアーキテクチャパターンを特定し、設計文書をReadツールで読み込み
- 再利用可能なユーティリティ関数やコンポーネントを確認し、関連ファイルをReadツールで読み込み
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フェーズ（コード改善）の作業を開始します。
## 信頼性レベル指示
リファクタリング時には、各改善内容について元の資料との照合状況を以下の信号でコメントしてください：
- 🔵 **青信号**: 元の資料を参考にしてほぼ推測していない場合
- 🟡 **黄信号**: 元の資料から妥当な推測の場合
- 🔴 **赤信号**: 元の資料にない推測の場合
## 目標
Greenフェーズで実装されたコードを以下の観点で改善してください。**テストは必ず通り続けること**が大前提です。
## 改善の観点
### 1. 可読性の向上
- 変数名・関数名の改善
- 日本語コメントの充実
- コードの構造を分かりやすく
### 2. 重複コードの除去（DRY原則）
- 同じような処理の共通化
- 定数の抽出
- ヘルパー関数の作成
### 3. 設計の改善
- 単一責任原則の適用
- 依存関係の整理
- モジュール化の検討
- NEVER: 実装コード内でのモック・スタブの記述
- NEVER: 実装コード内でDBに代わるインメモリーストレージの利用
### 4. ファイルサイズの最適化
- ファイルサイズが500行未満になるよう分割・最適化
- 長大なファイルの機能別分割
- 適切なモジュール境界の設定
### 5. コード品質の確保
- lintエラーの解消
- typecheckエラーの解消
- フォーマットの統一
- 静的解析ツールのチェッククリア
### 6. セキュリティレビュー
- 脆弱性に繋がる実装の検出と修正
- 入力値検証の強化
- SQLインジェクション対策の確認
- XSS（Cross-Site Scripting）対策の確認
- CSRF（Cross-Site Request Forgery）対策の確認
- データ漏洩リスクの回避
- 認証・認可の適切な実装
### 7. パフォーマンスレビュー
- アルゴリズムの計算量解析
- メモリ使用量の最適化
- 不要な処理の削除
- キャッシュ戦略の検討
- データベースクエリの最適化
- ループ処理の効率化
- 非同期処理の適切な実装
### 8. エラーハンドリングの充実
- 入力値の検証
- 適切なエラーメッセージ
- 例外処理の改善
## リファクタリング時の日本語コメント強化要件
リファクタリングでは既存の日本語コメントを改善し、新たなコメントを追加してください：
### 改善された関数・メソッドのコメント
```javascript
/**
* 【機能概要】: [リファクタ後の機能の詳細説明]
* 【改善内容】: [どのような改善を行ったかを説明]
* 【設計方針】: [なぜこの設計にしたかの理由]
* 【パフォーマンス】: [性能面での考慮事項]
* 【保守性】: [メンテナンスしやすくするための工夫]
* 🔵🟡🔴 信頼性レベル: [この改善が元資料のどの程度に基づいているか]
* @param {type} paramName - [パラメータの詳細説明と制約]
* @returns {type} - [戻り値の詳細説明と保証事項]
*/
function improvedFunction(paramName) {
// 【実装詳細】: [改善された実装の内容と理由]
}
```
### ヘルパー関数・ユーティリティのコメント
```javascript
/**
* 【ヘルパー関数】: [この関数の役割と作成理由]
* 【再利用性】: [どのような場面で再利用できるか]
* 【単一責任】: [この関数が担当する責任の範囲]
*/
function helperFunction(input) {
// 【処理効率化】: [処理を効率化するための工夫] 🔵🟡🔴
// 【可読性向上】: [コードの読みやすさを向上させる仕組み] 🔵🟡🔴
}
```
### 定数・設定値のコメント
```javascript
// 【設定定数】: [この定数の役割と設定理由] 🔵🟡🔴
// 【調整可能性】: [将来的に調整が必要になる可能性と方法] 🔵🟡🔴
const IMPROVED_CONSTANT = 100; // 【最適化済み】: パフォーマンステストに基づき最適化 🔵🟡🔴
// 【設定オブジェクト】: [設定をまとめた理由と管理方針]
const CONFIG = {
// 【各設定項目】: [それぞれの設定値の意味と影響範囲]
maxRetries: 3, // 【リトライ回数】: 実運用での経験に基づく適切な回数
timeout: 5000, // 【タイムアウト】: ユーザビリティを考慮した時間設定
};
```
### エラーハンドリング改善のコメント
```javascript
try {
// 【安全な処理実行】: [例外が発生する可能性と対策]
const result = riskyOperation();
} catch (error) {
// 【詳細エラー処理】: [エラーの種類に応じた適切な処理]
// 【ユーザビリティ】: [ユーザーにとって分かりやすいエラー対応]
if (error.code === 'SPECIFIC_ERROR') {
// 【特定エラー対応】: [このエラーに特化した処理の理由]
return handleSpecificError(error);
}
// 【一般エラー対応】: [予期しないエラーへの安全な対処]
return handleGenericError(error);
}
```
## リファクタリングの手順
1. **現在のテストが全て通ることを確認**
- 【品質保証】: リファクタ前の動作確認
- 【安全性確保】: 変更による機能破綻の防止
- 【実行方法】: Taskツールを使用してテストを実行し、結果を詳細に分析
2. **コード・テスト除外チェック**
- 【.gitignore確認】: 本来確認対象のコードファイルが除外されていないかチェック
- 【テスト除外確認】: `describe.skip`, `it.skip`, `test.skip`等でテストが無効化されていないかチェック
- 【jest設定確認】: `jest.config.js`や`package.json`の`testPathIgnorePatterns`等でテストファイルが除外されていないかチェック
- 【実行対象確認】: 実際に実行されるべきテストとコードが適切に対象に含まれているかチェック
3. **開発時生成ファイルのクリーンアップ**
- 【不要ファイル検出】: 開発中に作成された一時的なファイルを検出・削除
- 【対象ファイルパターン】: 以下のパターンに該当するファイルを確認
- `debug-*.js`, `debug-*.ts`: デバッグ用スクリプト
- `test-*.js`, `test-*.ts`, `temp-*.js`: 一時テストファイル
- `*.tmp`, `*.temp`, `*.bak`, `*.orig`: 一時・バックアップファイル
- `*~`, `.DS_Store`: エディタ・システム生成ファイル
- `test-output-*`, `*.test-output`: テスト出力ファイル
- 【安全確認】: 削除前に各ファイルの内容を確認し、重要なコードが含まれていないかチェック
- 【選択的削除】: 不要と判断されたファイルのみを削除し、必要なファイルは保持
- 【削除ログ】: 削除したファイルと削除理由をログとして記録
- 【実行手順】:
1. `find . -name "debug-*" -o -name "test-*" -o -name "temp-*" -o -name "*.tmp" -o -name "*.temp" -o -name "*.bak" -o -name "*.orig" -o -name "*~" -o -name ".DS_Store" | grep -v node_modules` でファイル検出
2. 各ファイルの内容をReadツールで確認
3. 不要と判断されたファイルは削除し、削除理由を記録
4. **セキュリティレビューの実施**
- 【脆弱性検査】: コード全体のセキュリティホールの特定
- 【入力検証確認】: 不正な入力値に対する防御機能の確認
- 【セキュリティガイドライン適用】: 業界標準のセキュリティベストプラクティスの適用
5. **パフォーマンスレビューの実施**
- 【計算量解析】: アルゴリズムの時間計算量・空間計算量の評価
- 【ボトルネック特定】: 処理速度やメモリ使用量の問題箇所の特定
- 【最適化戦略】: 具体的なパフォーマンス改善施策の立案
6. **小さな改善を1つずつ適用**
- 【段階的改善】: 影響範囲を限定した安全な変更
- 【トレーサビリティ】: 変更内容の追跡可能性確保
7. **各改善後にテストを実行**
- 【継続的検証】: 改善の度に動作確認
- 【早期発見】: 問題の早期発見と修正
- 【実行方法】: Taskツールを使用してテストを実行し、改善の影響を確認
8. **テストが失敗したら即座に戻す**
- 【迅速復旧】: 問題発生時の素早い対応
- 【安定性維持】: システムの安定した状態を保持
## 注意事項
- **機能的な変更は行わない**（新機能追加はNG）
- **テストが通らなくなったら即座に修正**
- **一度に大きな変更をしない**
- **日本語コメントの品質も向上させる**
- **品質確認のためのテスト実行時はTaskツールを利用する**
## 提供してください
1. **セキュリティレビュー結果**: 脆弱性の有無と対応策
2. **パフォーマンスレビュー結果**: 性能課題の分析と改善策
3. **改善されたコード**: リファクタリング後のコード（強化された日本語コメント付き）
4. **改善ポイントの説明**: 何をどのように改善したか（セキュリティ・パフォーマンス観点を含む）
5. **テスト実行結果**: Taskツールを使用して全てのテストが引き続き通ることの確認
6. **品質評価**: 現在のコードの品質レベル（セキュリティ・パフォーマンス評価を含む）
7. **コメント改善内容**: 日本語コメントをどのように強化したか
## リファクタリング例
```javascript
// Before: ハードコーディング
function add(a, b) {
return 5; // とりあえず動く実装
}
// After: 適切な実装（改善された日本語コメント付き）
/**
* 【機能概要】: 2つの数値を加算し、結果を返す
* 【改善内容】: ハードコーディングを削除し、実際の加算処理を実装
* 【設計方針】: 入力値検証と型安全性を重視した設計
* 【エラー処理】: 不正な入力に対する適切な例外処理を実装
*/
function add(firstNumber, secondNumber) {
// 【入力値検証】: 数値以外の入力を早期に検出してエラーを防ぐ
// 【型安全性】: TypeScriptの型チェックと併せて実行時検証を実施
if (typeof firstNumber !== 'number' || typeof secondNumber !== 'number') {
// 【ユーザビリティ】: 開発者にとって分かりやすいエラーメッセージを提供
throw new Error('引数は数値である必要があります');
}
// 【メイン処理】: シンプルで確実な加算処理
// 【パフォーマンス】: 不要な処理を避けた効率的な実装
return firstNumber + secondNumber;
}
```
リファクタリング完了後、以下を実行してください：
1. **メモファイル最終更新**: `docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md` ファイルのRefactorフェーズセクションと概要を更新
- 改善内容、セキュリティレビュー結果、パフォーマンスレビュー結果を記録
- 最終コード、品質評価を記録
- 概要セクションの現在のフェーズを「完了」に更新
2. リファクタリング内容と設計改善を `docs/implements/{要件名}/{{task_id}}/{feature_name}-refactor-phase.md` に保存（既存ファイルがある場合は追記）
3. TODOステータスを更新（Refactorフェーズ完了をマーク）
4. **品質判定**: リファクタリング成果の品質を以下の基準で判定
- テスト結果: 全てのテストが引き続き成功
- セキュリティ: 重大な脆弱性が発見されていない
- パフォーマンス: 重大な性能課題が発見されていない
- リファクタ品質: 目標が達成されている
- コード品質: 適切なレベルに向上
5. **次のステップ表示**: 判定結果に関わらず、次のお勧めコマンドを表示
- 「次のお勧めステップ: `/tsumiki:tdd-verify-complete` で完全性検証を実行します。」
## 品質判定基準
```
✅ 高品質:
- テスト結果: Taskツールによる実行で全て継続成功
- セキュリティ: 重大な脆弱性なし
- パフォーマンス: 重大な性能課題なし
- リファクタ品質: 目標達成
- コード品質: 適切なレベル
- ドキュメント: 完成
⚠️ 要改善:
- テストの一部失敗（Taskツールで検出）
- セキュリティ脆弱性発見
- パフォーマンス課題発見
- リファクタ目標未達成
- 品質改善不十分
- ドキュメント不備
```
## TODO更新パターン
```
- 現在のTODO「Refactorフェーズ（品質改善）」を「completed」にマーク
- リファクタリングフェーズの完了をTODO内容に反映
- 品質判定結果をTODO内容に記録
- 次のフェーズ「完全性検証」をTODOに追加
- 改善が必要な箇所がある場合は新たなTODOとして追加
```

145
commands/tdd-requirements.md Normal file
View File

@@ -0,0 +1,145 @@
---
description: TDD開発の要件整理を行います。機能要件を明確化し、テスト駆動開発のための準備を行います。
---
あなたは開発の要件整理担当者です。TASKから必要な情報を集めて必要な機能を網羅的に整理してください。
# TDD要件定義・機能仕様の整理
TDD開発を始めます。以下の機能について要件を整理してください：
**【機能名】**: {{feature_name}}
## 事前準備
開発コンテキストの準備を行います：
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ツールで読み込み
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要件定義の作業を開始します。
## TDD用要件整理フォーマット
**【信頼性レベル指示】**:
各項目について、元の資料（EARS要件定義書・設計文書含む）との照合状況を以下の信号でコメントしてください：
- 🔵 **青信号**: EARS要件定義書・設計文書を参考にしてほぼ推測していない場合
- 🟡 **黄信号**: EARS要件定義書・設計文書から妥当な推測の場合
- 🔴 **赤信号**: EARS要件定義書・設計文書にない推測の場合
## 1. 機能の概要（EARS要件定義書・設計文書ベース）
- 🔵🟡🔴 各項目の信頼性レベルを記載
- 何をする機能か（ユーザストーリーから抽出）
- どのような問題を解決するか（As a / So that から抽出）
- 想定されるユーザー（As a から抽出）
- システム内での位置づけ（アーキテクチャ設計から抽出）
- **参照したEARS要件**: [具体的な要件ID]
- **参照した設計文書**: [architecture.md の該当セクション]
## 2. 入力・出力の仕様（EARS機能要件・TypeScript型定義ベース）
- 🔵🟡🔴 各項目の信頼性レベルを記載
- 入力パラメータ（型、範囲、制約）- interfaces.tsから抽出
- 出力値（型、形式、例）- interfaces.tsから抽出
- 入出力の関係性
- データフロー（dataflow.mdから抽出）
- **参照したEARS要件**: [具体的なREQ-XXX]
- **参照した設計文書**: [interfaces.ts の該当インターフェース]
## 3. 制約条件（EARS非機能要件・アーキテクチャ設計ベース）
- 🔵🟡🔴 各項目の信頼性レベルを記載
- パフォーマンス要件（NFR-XXXから抽出）
- セキュリティ要件（NFR-XXXから抽出）
- 互換性要件（REQ-XXX MUSTから抽出）
- アーキテクチャ制約（architecture.mdから抽出）
- データベース制約（database-schema.sqlから抽出）
- API制約（api-endpoints.mdから抽出）
- **参照したEARS要件**: [具体的なNFR-XXX, REQ-XXX]
- **参照した設計文書**: [architecture.md, database-schema.sql等の該当セクション]
## 4. 想定される使用例（EARSEdgeケース・データフローベース）
- 🔵🟡🔴 各項目の信頼性レベルを記載
- 基本的な使用パターン（通常要件REQ-XXXから抽出）
- データフロー（dataflow.mdから抽出）
- エッジケース（EDGE-XXXから抽出）
- エラーケース（EDGE-XXXエラー処理から抽出）
- **参照したEARS要件**: [具体的なEDGE-XXX]
- **参照した設計文書**: [dataflow.md の該当フロー図]
## 5. EARS要件・設計文書との対応関係
既存のEARS要件定義書・設計文書を参照した場合、以下の対応関係を明記してください：
- **参照したユーザストーリー**: [ストーリー名]
- **参照した機能要件**: [REQ-001, REQ-002, ...]
- **参照した非機能要件**: [NFR-001, NFR-101, ...]
- **参照したEdgeケース**: [EDGE-001, EDGE-101, ...]
- **参照した受け入れ基準**: [具体的なテスト項目]
- **参照した設計文書**:
- **アーキテクチャ**: [architecture.md の該当セクション]
- **データフロー**: [dataflow.md の該当フロー図]
- **型定義**: [interfaces.ts の該当インターフェース]
- **データベース**: [database-schema.sql の該当テーブル]
- **API仕様**: [api-endpoints.md の該当エンドポイント]
整理後、以下を実行してください：
1. 要件定義書を `docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md` に保存（既存ファイルがある場合は追記）
2. TODOステータスを更新（要件定義完了をマーク）
3. **品質判定**: 要件の品質を以下の基準で判定
- 要件が明確で曖昧さがない
- 入出力仕様が具体的に定義されている
- 制約条件が明確
- 実装可能性が確実
4. **次のステップ表示**: 判定結果に関わらず、次のお勧めコマンドを表示
- 「次のお勧めステップ: `/tdd-testcases` でテストケースの洗い出しを行います。」
## 品質判定基準
```
✅ 高品質:
- 要件の曖昧さ: なし
- 入出力定義: 完全
- 制約条件: 明確
- 実装可能性: 確実
⚠️ 要改善:
- 要件に曖昧な部分がある
- 入出力の詳細が不明確
- 技術的制約が不明
- ユーザー意図の確認が必要
```
## TODO更新パターン
```
- 現在のTODOを「completed」にマーク
- 要件定義フェーズの完了をTODO内容に反映
- 次のフェーズ「テストケース洗い出し」をTODOに追加
- 品質判定結果をTODO内容に記録
```
次のステップ: `/tdd-testcases` でテストケースの洗い出しを行います。

202
commands/tdd-testcases.md Normal file
View File

@@ -0,0 +1,202 @@
---
description: TDD開発のためのテストケース洗い出しを行います。整理された要件に基づいて包括的なテストケースを特定します。
---
あなたはテスト設計の担当者です。指定されたtask_idの要件を確認して。網羅的なテストケースを作成してください。
# TDDテストケースの洗い出し
先ほど整理した要件に基づいて、要件網羅率と機能網羅率が十分に高いテストケースを洗い出します。
## 事前準備
開発コンテキストの準備を行います：
1. **追加ルールの読み込み**
- `docs/rule` ディレクトリが存在する場合は読み込み
- `docs/rule/tdd` ディレクトリが存在する場合は読み込み
- `docs/rule/tdd/testcases` ディレクトリが存在する場合は読み込み
- 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用
2. **@agent-symbol-searcher でテスト関連情報を検索し、見つかったファイルを読み込み**
- 既存のテストパターンやテストケースを検索し、該当テストファイルをReadツールで読み込み
- 類似機能のテスト方法やモック戦略を特定し、関連ファイルをReadツールで読み込み
- テストフレームワークの使用方法を確認し、設定ファイルをReadツールで読み込み
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` - 既存のテストケースを確認
- 関連する設計文書やタスクファイルも必要に応じて読み込み
読み込み完了後、準備されたコンテキスト情報を基にテストケースの洗い出しを行います。
## 信頼性レベル指示
各テストケースの作成時には、元の資料（要件定義、既存実装、ライブラリドキュメント等）との照合状況を以下の信号で必ずコメントしてください：
- 🔵 **青信号**: 元の資料を参考にしてほぼ推測していない場合
- 🟡 **黄信号**: 元の資料から妥当な推測の場合
- 🔴 **赤信号**: 元の資料にない推測の場合
## テストケースの分類
### 1. 正常系テストケース（基本的な動作）
以下の形式で記載してください：
- **テスト名**: [わかりやすい日本語名]
- **何をテストするか**: [このテストで確認したい具体的な動作や機能]
- **期待される動作**: [どのような処理が正常に実行されるべきか]
- **入力値**: [具体的な値]
- **入力データの意味**: [なぜこの入力値を選んだか、何を代表しているか]
- **期待される結果**: [具体的な期待値]
- **期待結果の理由**: [なぜこの結果が正しいとされるか]
- **テストの目的**: [何を確認するか]
- **確認ポイント**: [特に注意して検証すべき点]
- 🔵🟡🔴 このテストケースの信頼性レベルを記載
### 2. 異常系テストケース（エラーハンドリング）
- **テスト名**: [わかりやすい日本語名]
- **エラーケースの概要**: [どのような異常状況を想定しているか]
- **エラー処理の重要性**: [なぜこのエラーハンドリングが必要か]
- **入力値**: [不正な値や境界を超えた値]
- **不正な理由**: [なぜこの入力値が不正とされるか]
- **実際の発生シナリオ**: [実運用でどのような場面で発生するか]
- **期待される結果**: [適切なエラーメッセージや例外]
- **エラーメッセージの内容**: [ユーザーにとって分かりやすいメッセージか]
- **システムの安全性**: [エラー時にシステムが安全な状態を保てるか]
- **テストの目的**: [エラーハンドリングの確認]
- **品質保証の観点**: [このテストがシステム品質にどう貢献するか]
- 🔵🟡🔴 このテストケースの信頼性レベルを記載
### 3. 境界値テストケース（最小値、最大値、null等）
- **テスト名**: [わかりやすい日本語名]
- **境界値の意味**: [なぜこの値が境界として重要か]
- **境界値での動作保証**: [境界付近での動作の一貫性確認]
- **入力値**: [境界値]
- **境界値選択の根拠**: [なぜこの値を境界値として選んだか]
- **実際の使用場面**: [実運用でこの境界値がどう影響するか]
- **期待される結果**: [境界での動作]
- **境界での正確性**: [境界値での計算や処理が正確に行われるか]
- **一貫した動作**: [境界の内側と外側で動作が一貫しているか]
- **テストの目的**: [境界条件の確認]
- **堅牢性の確認**: [システムが極端な条件下でも安定動作するか]
- 🔵🟡🔴 このテストケースの信頼性レベルを記載
## 開発言語・フレームワーク
実装に使用する言語・テストフレームワークも併せて指定してください：
- **プログラミング言語**: {{language}}
- **言語選択の理由**: [なぜこの言語を選んだか]
- **テストに適した機能**: [この言語のテストに有利な特徴]
- **テストフレームワーク**: {{test_framework}}
- **フレームワーク選択の理由**: [なぜこのテストフレームワークを選んだか]
- **テスト実行環境**: [どのような環境でテストを実行するか]
- 🔵🟡🔴 この内容の信頼性レベルを記載
## テストケース実装時の日本語コメント指針
各テストケースの実装時には以下の日本語コメントを必ず含めてください：
### テストケース開始時のコメント
```javascript
// 【テスト目的】: [このテストで何を確認するかを日本語で明記]
// 【テスト内容】: [具体的にどのような処理をテストするかを説明]
// 【期待される動作】: [正常に動作した場合の結果を説明]
// 🔵🟡🔴 この内容の信頼性レベルを記載
```
### Given（準備フェーズ）のコメント
```javascript
// 【テストデータ準備】: [なぜこのデータを用意するかの理由]
// 【初期条件設定】: [テスト実行前の状態を説明]
// 【前提条件確認】: [テスト実行に必要な前提条件を明記]
```
### When（実行フェーズ）のコメント
```javascript
// 【実際の処理実行】: [どの機能/メソッドを呼び出すかを説明]
// 【処理内容】: [実行される処理の内容を日本語で説明]
// 【実行タイミング】: [なぜこのタイミングで実行するかを説明]
```
### Then（検証フェーズ）のコメント
```javascript
// 【結果検証】: [何を検証するかを具体的に説明]
// 【期待値確認】: [期待される結果とその理由を説明]
// 【品質保証】: [この検証がシステム品質にどう貢献するかを説明]
```
### 各expectステートメントのコメント
```javascript
// 【検証項目】: [この検証で確認している具体的な項目]
// 🔵🟡🔴 この内容の信頼性レベルを記載
expect(result.validPaths).toHaveLength(2); // 【確認内容】: 有効なパスが正確に2つ検出されることを確認
expect(result.invalidPaths).toContain('nonexistent.json'); // 【確認内容】: 存在しないファイルが無効パスとして適切に分類されることを確認
```
### セットアップ・クリーンアップのコメント
```javascript
beforeEach(() => {
// 【テスト前準備】: [各テスト実行前に行う準備作業の説明]
// 【環境初期化】: [テスト環境をクリーンな状態にする理由と方法]
});
afterEach(() => {
// 【テスト後処理】: [各テスト実行後に行うクリーンアップ作業の説明]
// 【状態復元】: [次のテストに影響しないよう状態を復元する理由]
});
```
すべて洗い出したら以下を実行してください：
1. テストケース一覧を `docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md` に保存（既存ファイルがある場合は追記）
2. TODOステータスを更新（テストケース洗い出し完了をマーク）
3. **品質判定**: テストケースの品質を以下の基準で判定
- テストケース分類: 正常系・異常系・境界値が網羅されている
- 期待値定義: 各テストケースの期待値が明確
- 技術選択: プログラミング言語・テストフレームワークが確定
- 実装可能性: 現在の技術スタックで実現可能
4. **次のステップ表示**: 判定結果に関わらず、次のお勧めコマンドを表示
- 「次のお勧めステップ: `/tsumiki:tdd-red` でRedフェーズ（失敗テスト作成）を開始します。」
## 品質判定基準
以下の基準でテストケースの品質を判定します：
```
✅ 高品質:
- テストケース分類: 正常系・異常系・境界値が網羅されている
- 期待値定義: 各テストケースの期待値が明確
- 技術選択: プログラミング言語・テストフレームワークが確定
- 実装可能性: 現在の技術スタックで実現可能
⚠️ 要改善:
- テストケースに漏れや重複がある
- 期待値が曖昧または不十分
- 技術選択に迷いがある
- 複雑すぎて実装困難
❌ 不適切:
- 要件との整合性が取れていない
- テストケースが不足している
- 技術的実現性に問題がある
```
## TODO更新パターン
```
- 現在のTODO「テストケース洗い出し」を「completed」にマーク
- テストケース定義フェーズの完了をTODO内容に反映
- 品質判定結果をTODO内容に記録
- 次のフェーズ「Redフェーズ（失敗テスト作成）」をTODOに追加
```

168
commands/tdd-todo.md Normal file
View File

@@ -0,0 +1,168 @@
---
description: タスクファイルから実装可能なTODOリストを作成します。段階的な実装計画を立て、効率的な開発を支援します。
---
あなたは実装可能なTODOリストを作成する専門家です。kairo-tasksコマンドで作成されたタスクファイルと関連する設計文書を分析し、以下の形式で構造化されたTODOリストを作成してください。
## 入力
- `docs/tasks/{要件名}-tasks.md` ファイル
- 各タスクのタスクID（{{task_id}}など）
- 要件定義文書：
- `docs/spec/{要件名}-requirements.md`
- 設計文書群：
- `docs/design/{要件名}/architecture.md`
- `docs/design/{要件名}/database-schema.sql`
- `docs/design/{要件名}/api-endpoints.md`
- `docs/design/{要件名}/interfaces.ts`
- `docs/design/{要件名}/dataflow.md`
## 作成手順
1. **追加ルールの読み込み**
- `docs/rule` ディレクトリが存在する場合は読み込み
- `docs/rule/tdd` ディレクトリが存在する場合は読み込み
- `docs/rule/tdd/todo` ディレクトリが存在する場合は読み込み
- 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用
2. **要件定義文書の分析**
- @agent-symbol-searcher で関連要件・設計文書を検索
- EARS記法による要件の理解
- ユーザストーリーと価値の把握
- 機能要件と非機能要件の確認
- Edgeケースと受け入れ基準の理解
3. **設計文書の分析**
- @agent-symbol-searcher で既存アーキテクチャパターンを検索
- アーキテクチャ設計の全体像を把握
- データベーススキーマの構造を理解
- APIエンドポイントの仕様を確認
- インターフェース定義を分析
- データフローの設計を理解
4. **タスクファイルの分析**
- @agent-symbol-searcher で関連タスクIDや完了状態を検索
- 全体のフェーズ構造を把握
- タスクID別の実装内容を確認
- 依存関係と実行順序を理解
- 要件定義と設計文書との整合性を確認
5. **TODO作成時の注意点**
- タスクIDを保持してトレーサビリティを確保
- 依存関係を考慮した順序付け
- 各タスクの完了条件を明確化
- テスト要件とUI/UX要件を含める
- 要件定義のREQとの対応関係を明記
- 受け入れ基準をTODOに反映
- Edgeケースの考慮事項を含める
- 設計文書の詳細を実装TODOに反映
- データベーススキーマとの整合性を確保
- API仕様との一貫性を保つ
- 実装方法の区別：
- **DIRECT**: 設定作業のみ（環境構築、設定ファイル、依存関係など）
- **TDD**: 仕様に合わせた実装を伴う作業（ビジネスロジック、API実装、UI実装など）
6. **出力形式**
```markdown
# {要件名} 実装TODO
## 概要
- 全タスク数: {数}
- 推定作業時間: {時間}
- クリティカルパス: {タスクID列}
- 参照要件: {REQ-001, REQ-002...}
- 設計文書: {参照した設計文書の概要}
## todo
### フェーズ1: 基盤構築
- [ ] **{{task_id}} [DIRECT]**: {{タスク名}} (REQ-{{XXX}}対応)
- [ ] {実装詳細1（architecture.mdから抽出）}
- [ ] {データベース設定（database-schema.sqlから抽出）}
- [ ] {テスト要件1}
- [ ] {受け入れ基準（requirements.mdから抽出）}
- [ ] {完了条件1}
- [ ] **{{task_id}} [DIRECT]**: {{タスク名}} (REQ-{{XXX}}対応)
- [ ] {実装詳細1（architecture.mdから抽出）}
- [ ] {環境設定（dataflow.mdから抽出）}
- [ ] {テスト要件1}
- [ ] {受け入れ基準（requirements.mdから抽出）}
- [ ] {完了条件1}
### フェーズ2: API実装
- [ ] **{{task_id}} [TDD]**: {{タスク名}} (REQ-{{XXX}}対応)
- [ ] {実装詳細1（api-endpoints.mdから抽出）}
- [ ] {インターフェース実装（interfaces.tsから抽出）}
- [ ] {テスト要件1}
- [ ] {エラーハンドリング1（Edgeケースから抽出）}
- [ ] {受け入れ基準（requirements.mdから抽出）}
### フェーズ3: フロントエンド実装
- [ ] **{{task_id}} [TDD]**: {{タスク名}} (REQ-{{XXX}}対応)
- [ ] {実装詳細1（interfaces.tsから抽出）}
- [ ] {データフロー実装（dataflow.mdから抽出）}
- [ ] {UI/UX要件1}
- [ ] {ユーザビリティ要件（NFR-201から抽出）}
- [ ] {テスト要件1}
- [ ] {受け入れ基準（requirements.mdから抽出）}
### フェーズ4: 統合・最適化
- [ ] **{{task_id}} [TDD]**: {{タスク名}} (REQ-{{XXX}}対応)
- [ ] {実装詳細1（全設計文書から抽出）}
- [ ] {E2Eテスト（dataflow.mdから抽出）}
- [ ] {パフォーマンス要件（NFR-001から抽出）}
- [ ] {セキュリティ要件（NFR-101から抽出）}
- [ ] {テスト要件1}
- [ ] {受け入れ基準（requirements.mdから抽出）}
## 実行順序
1. **基盤構築** ({タスクID列}) - 理由：他のタスクの前提条件
2. **API実装** ({タスクID列}) - 理由：フロントエンドの依存関係
3. **フロントエンド実装** ({タスクID列}) - 理由：ユーザーインターフェース
4. **統合・最適化** ({タスクID列}) - 理由：最終的な品質確保
## 実装プロセス
### TDDタスクの実装プロセス
[TDD]タスクは以下の順序で実装:
1. `/{taskID}/tdd-requirements.md` - 詳細要件定義（要件定義文書から抽出）
2. `/{taskID}/tdd-testcases.md` - テストケース作成（受け入れ基準とEdgeケースから導出）
3. `/{taskID}/tdd-red.md` - テスト実装（失敗）
4. `/{taskID}/tdd-green.md` - 最小実装（アーキテクチャ設計に準拠）
5. `/{taskID}/tdd-refactor.md` - リファクタリング（設計文書との整合性確認）
6. `/{taskID}/tdd-verify-complete.md` - 品質確認（要件定義の受け入れ基準で検証）
### DIRECTタスクの実装プロセス
[DIRECT]タスクは以下の順序で実装:
1. `/{taskID}/direct-setup.md` - 設定作業の実行（設計文書に基づく）
2. `/{taskID}/direct-verify.md` - 設定確認（動作確認とテスト）
## 文書との連携
- **{要件名}-requirements.md**: 機能要件（REQ-XXX）、非機能要件（NFR-XXX）、受け入れ基準
- **architecture.md**: 全体的な実装方針とアーキテクチャパターン
- **database-schema.sql**: データベース関連タスクの実装詳細
- **api-endpoints.md**: API実装タスクの仕様と検証条件
- **interfaces.ts**: フロントエンド・バックエンド間の契約
- **dataflow.md**: データ処理フローと統合テストシナリオ
```
1. **フィードバック対応** TODOリスト提示後、ユーザーからのフィードバックに基づいて以下を調整：
- タスクの粒度（より細かく/大きく）
- 優先順位の変更
- 不足しているタスクの追加
- 不要なタスクの削除
- 実装方針の変更

412
commands/tdd-verify-complete.md Normal file
View File

@@ -0,0 +1,412 @@
---
description: TDD開発でテストケースの実装が完全に完了しているかを検証します。すべてのテストが通ることを確認し、開発完了を保証します。
---
# TDD テストケース完全性検証
TDD開発でテストケースの実装が完全に完了しているかを検証します。
## 検証の目的
リファクタリング後に、予定していたテストケースがすべて実装されているかを確認し、実装漏れを防ぎます。
## 重要な原則
**⚠️ この工程では修正を行わない**
- この検証フェーズではコードやテストの修正は一切行わない
- 問題を発見した場合は内容をmemoファイルに記載する
- 修正作業は後の工程（次のTDDサイクルや別のタスク）に委ねる
- 検証・記録・報告に専念する
- テストの実行は @task で実行する
- NEVER 全体のテストケースの実装率と成功率のレポートは省略しない
## 検証手順
### 1. 既存テストのグリーン状態確認
- **必須**: 全ての既存テストが成功していることを確認
- `npm test` または `jest` を実行してテスト結果を確認
- **テスト失敗がある場合**: memoファイルに記載し、後の工程で修正対応
- **この工程では修正禁止**: テスト失敗を発見してもここでは修正しない
- テスト状態を記録し、次のステップに進む
### 2. 事前準備
検証コンテキストの準備を行います：
1. **追加ルールの読み込み**
- `AGENTS.md` ファイルが存在する場合は読み込み
- `docs/rule` ディレクトリが存在する場合は読み込み
- `docs/rule/tdd` ディレクトリが存在する場合は読み込み
- `docs/rule/tdd/verify-complete` ディレクトリが存在する場合は読み込み
- 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用
2. **@agent-symbol-searcher で検証関連情報を検索し、見つかったファイルを読み込み**
- 完了予定のテストケースや機能を検索し、該当ファイルをReadツールで読み込み
- 既存のテストカバレッジや品質基準を確認し、関連ファイルをReadツールで読み込み
- 実装完了タスクのマーキングパターンを特定し、タスクファイルをReadツールで読み込み
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`) - タスクの完了状態を確認
読み込み完了後、準備されたコンテキスト情報を基にテストケース完全性検証を開始します。
### 2. 実装済みテストケースの確認
- 現在のテストファイルを確認
- 実装済みテストケース数をカウント
- 各テストケースの内容を予定と照合
### 3. 実装状況の分析とTODO.md更新判定
以下の形式で分析結果を提供してください：
```
## テストケース実装状況
### 📋 TODO.md対象タスク確認
- **対象タスク**: [現在のTDD開発対象タスク名]
- **現在のステータス**: [未完了/部分完了/完了済み]
- **完了マーク要否**: [要/不要]
### 📋 予定テストケース（要件定義より）
- **総数**: [予定していた総テストケース数]
- **分類**:
- 正常系: [数]個
- 異常系: [数]個
- エッジケース: [数]個
- その他: [数]個
### ✅ 実装済みテストケース
- **総数**: [実装済み総テストケース数]
- **成功率**: [通過テスト数]/[実装テスト数] ([成功率]%)
### ❌ 未実装テストケース（[数]個）
1. **テストケース名**: [予定していたが未実装のテスト]
- **種類**: [正常系/異常系/エッジケース]
- **内容**: [テストの詳細内容]
- **重要度**: [高/中/低]
- **要件項目**: [対応する要件定義書の項目]
2. **テストケース名**: [2つ目の未実装テスト]
...
### 📋 要件定義書網羅性チェック
- **要件項目総数**: [要件定義書の総項目数]
- **実装済み項目**: [実装・テスト済みの項目数]
- **要件網羅率**: [実装済み]/[総数] = [網羅率]%
#### 未網羅の要件項目（[数]個）
1. **要件項目**: [未実装の要件項目名]
- **分類**: [入力パラメータ/出力仕様/制約条件/使用例/エラーケース等]
- **内容**: [要件の詳細内容]
- **実装不足の理由**: [なぜ未実装なのか]
- **対応の必要性**: [必須/推奨/任意]
2. **要件項目**: [2つ目の未網羅項目]
...
### 📊 実装率
- **全体実装率**: [実装数]/[予定数] = [実装率]%
- **正常系実装率**: [実装数]/[予定数] = [実装率]%
- **異常系実装率**: [実装数]/[予定数] = [実装率]%
- **エッジケース実装率**: [実装数]/[予定数] = [実装率]%
```
### 4. 判定基準
#### ✅ 完全実装済み（自動で次ステップ）
```
- 既存テスト状態: すべてグリーン
- 要件網羅率: 100%（全要件項目実装・テスト済み）
- テスト成功率: 100%
- 未実装重要要件: 0個
- 品質基準: 要件定義に対する完全な充実度を達成
```
#### ⚠️ 実装不足あり（追加実装必要）
```
- 既存テスト状態: 失敗テストあり または
- 要件網羅率: 100%未満（要件定義の項目に対する実装不足）
- 重要な要件項目が未実装・未テスト
- 要件充実度に品質リスクあり
```
### 5. 検証結果のメモファイル記録とTODO.md更新
#### メモファイルの統合更新
検証完了後、`docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md` の既存内容を整理・統合し、以下の情報に更新：
```markdown
# [機能名] TDD開発完了記録
## 確認すべきドキュメント
- `docs/tasks/{taskファイルのパス}.md`
- `docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md`
- `docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md`
## 🎯 最終結果 ([日時])
- **実装率**: [数]% ([実装数]/[予定数]テストケース)
- **品質判定**: [合格/不合格]
- **TODO更新**: [✅完了マーク追加/要改善]
## 💡 重要な技術学習
### 実装パターン
[今後再利用できる重要な実装手法]
### テスト設計
[効果的だったテストアプローチ]
### 品質保証
[品質確保で重要だった観点]
## ⚠️ 注意点・修正が必要な項目（該当時のみ）
[実装時の重要な注意事項や未完了項目]
### 🔧 後工程での修正対象
#### テスト失敗
- [失敗しているテストケース名]
- **失敗内容**: [具体的な失敗内容]
- **修正方針**: [推奨される修正方法]
#### 実装不足
- [未実装の機能や要件]
- **不足内容**: [具体的な不足内容]
- **対応方針**: [推奨される対応方法]
#### 品質改善
- [品質向上が必要な箇所]
- **改善内容**: [具体的な改善内容]
- **改善方針**: [推奨される改善方法]
---
*既存のメモ内容から重要な情報を統合し、重複・詳細な経過記録は削除*
```
**統合更新ルール:**
1. **重要情報保持**: 既存メモの技術的学習ポイント・再利用可能パターンを統合
2. **重複削除**: 類似の記録・詳細な経過は最新情報に集約
3. **簡潔化**: 日付・数値などの詳細は最終結果のみ保持
4. **再利用重視**: 今後の開発で参考になる情報を優先して残す
5. **関連情報重視**: 仕様情報などの情報は優先して残す
#### 元タスクファイル完了マーク自動更新
検証が完了した場合、以下の手順で元タスクファイルを自動更新：
1. **完了タスクの特定**: 現在のTDD開発対象タスクを元タスクファイルから特定
2. **完了マーク追加**: 該当タスクに `✅ **完了**` マークを追加
3. **完了理由記載**: `(TDD開発完了 - [テスト数]テストケース全通過)` を追記
4. **サブタスク更新**: 関連するサブタスクにも `[x]` チェックマークを追加
例：
```markdown
### 1. JSONファイルパス引数処理機能 ✅ **完了** (TDD開発完了 - 15テストケース全通過)
- [x] コマンドライン引数でJSONファイルパスを受け取る機能を追加
- [x] 複数のJSONファイルパスに対応（sample/ディレクトリ全体の読み込み）
- [x] 引数バリデーション機能
```
### 6. 対応アクション
#### 完全実装済みの場合
以下のメッセージと共に次のお勧めコマンドを表示：
```
✅ テストケース完全性検証: 合格
- 予定テストケース: [数]個すべて実装済み
- テスト成功率: 100%
- 品質基準: 達成
次のお勧めステップ: `/tsumiki:tdd-cycle` で次のTDDサイクルを開始します。
```
**メモファイル記録**: 検証結果をメモファイルに自動追記する。
**元タスクファイル更新**: 完了したタスクに✅完了マークを自動追加する。
#### 実装不足がある場合
以下のメッセージを提供し、状況を記録する：
```
⚠️ テストケース実装不足を検出
未実装テストケース（[数]個）があります。
以下の内容をmemoファイルに記録しました：
[未実装テストケースのリスト]
【重要】この工程では修正を行いません。
修正が必要な内容はmemoファイルに記載され、後の工程で対応されます。
現状の記録を完了し、次のステップに進みます。
```
**メモファイル記録**: 実装不足の検証結果と修正方針をメモファイルに詳細記録する。
**元タスクファイル更新**: 実装不足の場合でも、部分完了したタスクがあれば適切にマークする。
**修正作業禁止**: この工程では一切の修正作業を行わない。
## 検証対象ファイル
### 確認すべきドキュメント
- **元タスクファイル**: `docs/tasks/{taskファイルのパス}.md` - プロジェクト全体のタスク完了状況（完了マーク更新対象）
- `docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md`
- `docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md`
### 確認すべきテストファイル
- `src/__tests__/*.test.ts`
- `src/__tests__/*.test.js`
### 確認すべき実装ファイル
- `src/*.ts`
- `src/*.js`
### Gitで変更されたファイル
- `git status` で変更されたファイル
- `git diff --name-only` で変更されたファイル
## 品質基準
### 最低品質基準
- **実装率**: 80%以上
- **成功率**: 100%
- **重要テスト**: すべて実装
- **要件網羅性**: 要件定義書の主要機能をすべて網羅
- **コンパイルエラー**: なし
### 理想品質基準
- **実装率**: 100%
- **成功率**: 100%
- **網羅性**: 全ケース対応
- **要件完全網羅**: 要件定義書の全項目を網羅
### 要件定義書の網羅性チェック
要件定義書（requirements.md）に記載された以下の項目が実装・テストされているかを確認：
#### 必須チェック項目
- **入力パラメータ**: 全ての必須・オプション引数の処理
- **出力仕様**: 期待される出力形式・構造の実装
- **制約条件**: パフォーマンス・セキュリティ・互換性要件
- **基本使用例**: 想定される基本的な使用パターン
- **エッジケース**: 境界値・例外条件の処理
- **エラーケース**: 異常系の適切な処理
- **主要アルゴリズム**: 機能の核となる処理ロジック
#### 網羅性判定基準
```
✅ 完全網羅 (100%):
- 要件定義書の全項目が実装・テストされている
- 入力パラメータの全パターンをテスト
- 出力仕様の全形式を検証
- エラーケース・エッジケースを全て網羅
⚠️ 部分網羅 (80-99%):
- 主要機能は実装されているが一部項目が未実装
- 基本的な使用例は網羅されている
- 重要でないエラーケースの一部が未実装
❌ 不十分 (<80%):
- 要件定義書の重要な項目が未実装
- 基本的な使用例に漏れがある
- エラーハンドリングが不十分
```
## 自動遷移判定
### 品質判定基準
```
✅ 高品質（要件充実度完全達成）:
- 既存テスト状態: すべてグリーン
- 要件網羅率: 100%（要件定義書の全項目に対する完全な実装・テスト）
- テスト成功率: 100%
- 未実装重要要件: 0個
- 要件充実度: 要件定義に対する完全な充実度を達成
⚠️ 要改善（要件充実度不足）:
- 既存テスト状態: 失敗テストあり または
- 要件網羅率: 100%未満（要件定義書の項目に対する実装・テスト不足）
- 重要な要件項目が未実装・未テスト
- 要件充実度: 要件定義に対する充実度が不十分
- 追加実装による要件充実度向上が必要
```
## 使用例
```bash
# refactorフェーズ後に自動実行
/tsumiki:tdd-refactor
# ↓ 自動実行
/tsumiki:tdd-verify-complete
# ↓ 実装完全なら自動実行
/tsumiki:tdd-cycle
```
## 出力形式
実装状況に応じて以下のいずれかの形式で出力：
### 完全実装の場合
```
✅ **テストケース完全性検証: 合格**
📊 今回のタスク要件充実度:
- 対象要件項目: [数]個
- 実装・テスト済み: [数]個 / 未実装: [数]個
- 要件網羅率: 100%
- 要件充実度: 完全達成
📊 全体のテスト状況:
- 全テストケース総数: [数]個
- 成功: [数]個 / 失敗: [数]個
- 全体テスト成功率: [数]%
🚀 要件定義に対する完全な充実度を達成しました。
自動で次のTDDサイクルに進みます。
```
### 実装不足の場合
```
⚠️ **テストケース実装不足を検出**
📊 今回のタスク要件充実度:
- 対象要件項目: [数]個
- 実装・テスト済み: [数]個 / 未実装: [数]個
- 要件網羅率: [数]%
- 要件充実度: [充実度レベル]
📊 全体のテスト状況:
- 全テストケース総数: [数]個
- 成功: [数]個 / 失敗: [数]個
- 全体テスト成功率: [数]%
❌ 未実装テストケース:
[未実装テストケースの詳細リスト]
📝 **修正内容をmemoファイルに記録済み**
後の工程で対応予定です。この工程では修正を行いません。
```
この検証により、TDD開発の品質と完全性を確保します。

105
commands/tech-stack.md Normal file
View File

@@ -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` を作成して上書きしてください。