diff --git a/commands/direct-verify.md b/commands/direct-verify.md
index 8db6eff..0e1e81a 100644
--- a/commands/direct-verify.md
+++ b/commands/direct-verify.md
@@ -12,19 +12,27 @@ DIRECTタスクで実行した設定作業の動作確認とテストを行い
 
 ## 実行内容
 
+**【重要】**: direct-setupで作成されたファイルについて、コンパイルエラーや構文エラーが見つかった場合は自動的に解決を試行します。
+
 1. **設定の確認**
    - 環境変数の確認
    - 設定ファイルの内容確認
    - 依存関係のインストール状況確認
    - サービスの起動状況確認
 
-2. **動作テストの実行**
+2. **コンパイル・構文確認**
+   - TypeScript/JavaScript構文エラーチェック（該当する場合）
+   - 設定ファイルの構文確認（JSON, YAML等）
+   - SQL構文確認（該当する場合）
+   - 最低限のコンパイルエラー解消
+
+3. **動作テストの実行**
    - 基本的な動作確認
    - 接続テスト
    - 権限の確認
    - エラーケースの確認
 
-3. **品質チェック**
+4. **品質チェック**
    - セキュリティ設定の確認
    - パフォーマンス基準の確認
    - ログの確認
@@ -77,6 +85,53 @@ cat config/database.json | jq .
 - [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
@@ -175,14 +230,42 @@ ps aux | grep node
 - [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: 手動対応が必要（詳細は推奨事項に記載）
 
 ## 推奨事項
 
@@ -214,6 +297,7 @@ ps aux | grep node
 ### 完了条件
 以下の条件を全て満たす場合にタスクを完了とマークします：
 - [ ] 全ての設定確認項目がクリア
+- [ ] コンパイル・構文チェックが成功（エラーがすべて解決済み）
 - [ ] 全ての動作テストが成功
 - [ ] 品質チェック項目が基準を満たしている
 - [ ] 発見された問題が適切に対処されている
diff --git a/commands/kairo-design.md b/commands/kairo-design.md
index 01ea8f0..01d6344 100644
--- a/commands/kairo-design.md
+++ b/commands/kairo-design.md
@@ -1,14 +1,23 @@
 # kairo-design
 
 ## 目的
+
 承認された要件定義書に基づいて、技術設計文書を生成する。データフロー図、TypeScriptインターフェース、データベーススキーマ、APIエンドポイントを含む包括的な設計を行う。
 
 ## 前提条件
+
 - `docs/spec/` に要件定義書が存在する
 - 要件がユーザによって承認されている
 
 ## 実行内容
 
+**【信頼性レベル指示】**:
+各項目について、元の資料（EARS要件定義書・設計文書含む）との照合状況を以下の信号でコメントしてください：
+
+- 🟢 **青信号**: EARS要件定義書・設計文書を参考にしてほぼ推測していない場合
+- 🟡 **黄信号**: EARS要件定義書・設計文書から妥当な推測の場合
+- 🔴 **赤信号**: EARS要件定義書・設計文書にない推測の場合
+
 1. **要件の分析**
    - 要件定義書を読み込む
    - 機能要件と非機能要件を整理する
@@ -52,61 +61,73 @@
 ## 出力フォーマット例
 
 ### architecture.md
+
 ```markdown
 # {要件名} アーキテクチャ設計
 
 ## システム概要
+
 {システムの概要説明}
 
 ## アーキテクチャパターン
+
 - パターン: {選択したパターン}
 - 理由: {選択理由}
 
 ## コンポーネント構成
+
 ### フロントエンド
+
 - フレームワーク: {使用フレームワーク}
 - 状態管理: {状態管理方法}
 
 ### バックエンド
+
 - フレームワーク: {使用フレームワーク}
 - 認証方式: {認証方法}
 
 ### データベース
+
 - DBMS: {使用するDBMS}
 - キャッシュ: {キャッシュ戦略}
 ```
 
 ### dataflow.md
+
 ```markdown
 # データフロー図
 
 ## ユーザーインタラクションフロー
+
 \`\`\`mermaid
 flowchart TD
-    A[ユーザー] --> B[フロントエンド]
-    B --> C[API Gateway]
-    C --> D[バックエンド]
-    D --> E[データベース]
+A[ユーザー] --> B[フロントエンド]
+B --> C[API Gateway]
+C --> D[バックエンド]
+D --> E[データベース]
 \`\`\`
 
 ## データ処理フロー
+
 \`\`\`mermaid
 sequenceDiagram
-    participant U as ユーザー
-    participant F as フロントエンド
-    participant B as バックエンド
-    participant D as データベース
-    
+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 {
@@ -135,6 +156,7 @@ export interface ApiResponse<T> {
 ```
 
 ### database-schema.sql
+
 ```sql
 -- ユーザーテーブル
 CREATE TABLE users (
@@ -150,38 +172,46 @@ CREATE INDEX idx_users_email ON users(email);
 ```
 
 ### api-endpoints.md
+
 ```markdown
 # API エンドポイント仕様
 
 ## 認証
+
 ### POST /auth/login
+
 リクエスト:
 \`\`\`json
 {
-  "email": "user@example.com",
-  "password": "password"
+"email": "user@example.com",
+"password": "password"
 }
 \`\`\`
 
 レスポンス:
 \`\`\`json
 {
-  "success": true,
-  "data": {
-    "token": "jwt-token",
-    "user": { ... }
-  }
+"success": true,
+"data": {
+"token": "jwt-token",
+"user": { ... }
+}
 }
 \`\`\`
 
 ## ユーザー管理
+
 ### GET /users/:id
+
 ### POST /users
+
 ### PUT /users/:id
+
 ### DELETE /users/:id
 ```
 
 ## 実行後の確認
+
 - 作成したファイルの一覧を表示
 - 設計の主要なポイントをサマリーで表示
 - ユーザに確認を促すメッセージを表示
diff --git a/commands/kairo-implement.md b/commands/kairo-implement.md
index 21744fa..20bc374 100644
--- a/commands/kairo-implement.md
+++ b/commands/kairo-implement.md
@@ -1,9 +1,11 @@
 # kairo-implement
 
 ## 目的
+
 分割されたタスクを順番に、またはユーザが指定したタスクを実装する。既存のTDDコマンドを活用して品質の高い実装を行う。
 
 ## 前提条件
+
 - `docs/tasks/{要件名}-tasks.md` にタスク一覧が存在する
 - ユーザがタスクの実装を承認している
 - 既存のTDDコマンドが利用可能である
@@ -11,6 +13,13 @@
 
 ## 実行内容
 
+**【信頼性レベル指示】**:
+各項目について、元の資料（EARS要件定義書・設計文書含む）との照合状況を以下の信号でコメントしてください：
+
+- 🟢 **青信号**: EARS要件定義書・設計文書を参考にしてほぼ推測していない場合
+- 🟡 **黄信号**: EARS要件定義書・設計文書から妥当な推測の場合
+- 🔴 **赤信号**: EARS要件定義書・設計文書にない推測の場合
+
 1. **タスクの選択**
    - ユーザが指定したタスクIDを確認
    - 指定がない場合は、依存関係に基づいて次のタスクを自動選択
diff --git a/commands/kairo-requirements.md b/commands/kairo-requirements.md
index bb11c34..13dc293 100644
--- a/commands/kairo-requirements.md
+++ b/commands/kairo-requirements.md
@@ -11,6 +11,13 @@
 
 ## 実行内容
 
+**【信頼性レベル指示】**:
+各項目について、元の資料（EARS要件定義書・設計文書含む）との照合状況を以下の信号でコメントしてください：
+
+- 🟢 **青信号**: EARS要件定義書・設計文書を参考にしてほぼ推測していない場合
+- 🟡 **黄信号**: EARS要件定義書・設計文書から妥当な推測の場合
+- 🔴 **赤信号**: EARS要件定義書・設計文書にない推測の場合
+
 1. **要件の分析**
    - ユーザから提供された要件の概要を理解する
    - 関連するドメイン知識を適用する
@@ -34,11 +41,15 @@
    - パフォーマンス要件
 
 5. **ファイルの作成**
-   - `docs/spec/{要件名}-requirements.md` として保存
+   - `docs/spec/{要件名}-requirements.md`: 機能要件と関連文書へのリンク
+   - `docs/spec/{要件名}-user-stories.md`: 詳細なユーザストーリー
+   - `docs/spec/{要件名}-acceptance-criteria.md`: 受け入れ基準とテスト項目
    - マークダウン形式で構造化された文書を作成
 
 ## 出力フォーマット例
 
+### 1. requirements.md（メインファイル）
+
 ```markdown
 # {要件名} 要件定義書
 
@@ -46,13 +57,10 @@
 
 {要件の概要}
 
-## ユーザストーリー
-
-### ストーリー1: {タイトル}
+## 関連文書
 
-- **である** {ユーザー種別} **として**
-- **私は** {実現したいこと} **をしたい**
-- **そうすることで** {得られる価値}
+- **ユーザストーリー**: [📖 {要件名}-user-stories.md]({要件名}-user-stories.md)
+- **受け入れ基準**: [✅ {要件名}-acceptance-criteria.md]({要件名}-acceptance-criteria.md)
 
 ## 機能要件（EARS記法）
 
@@ -101,20 +109,243 @@
 ### 境界値
 
 - EDGE-101: {境界値ケース}
+```
+
+### 2. user-stories.md（詳細なユーザストーリー）
+
+```markdown
+# {要件名} ユーザストーリー
+
+## 概要
+
+このドキュメントは{要件名}機能の詳細なユーザストーリーを記載します。
+
+## ユーザー種別の定義
+
+### プライマリユーザー
+
+- **エンドユーザー**: {エンドユーザーの詳細説明}
+- **管理者**: {管理者の詳細説明}
+- **開発者**: {開発者の詳細説明}
+
+### セカンダリユーザー
+
+- **システム管理者**: {システム管理者の詳細説明}
+- **外部システム**: {外部システムの詳細説明}
+
+## ユーザストーリー
+
+### 📚 エピック1: {大きな機能グループ}
+
+#### ストーリー1.1: {具体的なストーリー名}
+
+**ユーザストーリー**:
+- **私は** {ユーザー種別} **として**
+- **{具体的な状況・コンテキスト} において**
+- **{実現したい行動・操作} をしたい**
+- **そうすることで** {得られる価値・解決される問題}
+
+**詳細説明**:
+- **背景**: {なぜこの機能が必要なのか}
+- **前提条件**: {このストーリーの前提となる状況}
+- **利用シーン**: {具体的な利用場面の例}
+- **期待する体験**: {ユーザーが期待する体験の詳細}
+
+**関連要件**: 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: {代表的ユーザー名}
+
+- **基本情報**: {年齢、職業、技術レベル等}
+- **ゴール**: {このユーザーが達成したいこと}
+- **課題**: {現在抱えている問題}
+- **行動パターン**: {典型的な行動の特徴}
+- **利用環境**: {使用するデバイス、環境等}
+
+## 非機能的ユーザー要求
+
+### ユーザビリティ要求
+
+- **学習容易性**: {初回利用時の学習コスト}
+- **効率性**: {熟練後の作業効率}
+- **記憶しやすさ**: {再利用時の記憶のしやすさ}
+- **エラー対応**: {エラー時の対応しやすさ}
+- **満足度**: {主観的な満足度}
+
+### アクセシビリティ要求
+
+- **視覚**: {視覚障害者への配慮}
+- **聴覚**: {聴覚障害者への配慮}
+- **運動**: {運動機能障害者への配慮}
+- **認知**: {認知障害者への配慮}
+```
+
+### 3. acceptance-criteria.md（受け入れ基準）
+
+```markdown
+# {要件名} 受け入れ基準
+
+## 概要
+
+このドキュメントは{要件名}機能の受け入れ基準とテスト項目を記載します。
+
+## 機能テスト基準
+
+### REQ-001: {要件名} の受け入れ基準
+
+**Given（前提条件）**:
+- {テスト実行前の状態}
+- {必要な初期データ}
+
+**When（実行条件）**:
+- {実行するアクション}
+- {入力するデータ}
+
+**Then（期待結果）**:
+- {期待される出力・状態}
+- {確認すべき副作用}
+
+**テストケース**:
+- [ ] 正常系: {正常なケースの詳細}
+- [ ] 異常系: {異常なケースの詳細}
+- [ ] 境界値: {境界値テストの詳細}
+
+### REQ-002: {要件名} の受け入れ基準
+
+{同様の形式で記載}
+
+## 非機能テスト基準
+
+### パフォーマンステスト
+
+**NFR-001: {パフォーマンス要件}**
+
+- [ ] 応答時間: {具体的な時間基準}
+- [ ] スループット: {処理量の基準}
+- [ ] 同時接続数: {同時利用者数の基準}
+- [ ] リソース使用量: {CPU・メモリ使用量の基準}
+
+**テスト方法**:
+- 負荷テストツール: {使用するツール}
+- テストシナリオ: {具体的なテスト手順}
+- 合格基準: {定量的な合格ライン}
+
+### セキュリティテスト
+
+**NFR-101: {セキュリティ要件}**
+
+- [ ] 認証: {認証機能のテスト項目}
+- [ ] 認可: {権限制御のテスト項目}
+- [ ] データ保護: {データ暗号化のテスト項目}
+- [ ] 脆弱性: {セキュリティ脆弱性のテスト項目}
+
+## ユーザビリティテスト基準
+
+### UX/UIテスト
+
+- [ ] 直感的操作性: {操作の分かりやすさ}
+- [ ] レスポンシブデザイン: {各デバイスでの表示}
+- [ ] アクセシビリティ: {WCAG 2.1準拠}
+- [ ] エラーメッセージ: {分かりやすいエラー表示}
+
+**テスト方法**:
+- ユーザビリティテスト: {実施方法}
+- A/Bテスト: {比較テストの方法}
+- アクセシビリティチェック: {使用するツール}
+
+## Edgeケーステスト基準
+
+### EDGE-001: {エラーケース} の受け入れ基準
+
+**テストシナリオ**:
+- {異常な状況の設定}
+- {期待されるエラーハンドリング}
+- {ユーザーへの適切な通知}
+
+**合格基準**:
+- [ ] システムがクラッシュしない
+- [ ] 適切なエラーメッセージが表示される
+- [ ] データの整合性が保たれる
+- [ ] 復旧可能な状態を維持する
+
+## 統合テスト基準
+
+### システム間連携テスト
+
+- [ ] 外部API連携: {外部システムとの連携テスト}
+- [ ] データベース連携: {DB操作の整合性テスト}
+- [ ] ファイルシステム: {ファイル操作のテスト}
+
+## リグレッションテスト基準
+
+### 既存機能影響確認
+
+- [ ] 既存機能の動作確認: {影響範囲の特定と確認}
+- [ ] パフォーマンス劣化確認: {既存機能の性能確認}
+- [ ] セキュリティ設定確認: {セキュリティ機能の継続確認}
+
+## 受け入れテスト実行チェックリスト
+
+### テスト実行前
 
-## 受け入れ基準
+- [ ] テスト環境の準備完了
+- [ ] テストデータの準備完了
+- [ ] テストツールの準備完了
+- [ ] 実行担当者の確認完了
 
-### 機能テスト
+### テスト実行中
 
-- [ ] {テスト項目}
+- [ ] 全機能テストの実行
+- [ ] 全非機能テストの実行
+- [ ] 問題発見時の記録
+- [ ] 修正後の再テスト
 
-### 非機能テスト
+### テスト完了後
 
-- [ ] {テスト項目}
+- [ ] テスト結果の記録
+- [ ] 残存問題の整理
+- [ ] 受け入れ可否の判定
+- [ ] ステークホルダーへの報告
 ```
 
 ## 実行後の確認
 
-- 作成したファイルのパスを表示
-- 主要な要件の数を報告
+- 作成した3つのファイルのパスを表示
+  - `docs/spec/{要件名}-requirements.md`
+  - `docs/spec/{要件名}-user-stories.md` 
+  - `docs/spec/{要件名}-acceptance-criteria.md`
+- 主要な要件の数とユーザストーリー数を報告
+- 各ファイル内のリンクが正しく設定されていることを確認
 - ユーザに確認を促すメッセージを表示
diff --git a/commands/kairo-task-verify.md b/commands/kairo-task-verify.md
index 08e7aff..c0d613d 100644
--- a/commands/kairo-task-verify.md
+++ b/commands/kairo-task-verify.md
@@ -11,6 +11,13 @@
 
 ## 実行内容
 
+**【信頼性レベル指示】**:
+各項目について、元の資料（EARS要件定義書・設計文書含む）との照合状況を以下の信号でコメントしてください：
+
+- 🟢 **青信号**: EARS要件定義書・設計文書を参考にしてほぼ推測していない場合
+- 🟡 **黄信号**: EARS要件定義書・設計文書から妥当な推測の場合
+- 🔴 **赤信号**: EARS要件定義書・設計文書にない推測の場合
+
 1. **タスクファイルの確認**
    - `docs/tasks/{要件名}-tasks.md` を読み込み
 
diff --git a/commands/kairo-tasks.md b/commands/kairo-tasks.md
index 4d07e15..4887439 100644
--- a/commands/kairo-tasks.md
+++ b/commands/kairo-tasks.md
@@ -1,15 +1,24 @@
 # kairo-tasks
 
 ## 目的
-設計文書に基づいて実装タスクを分割し、依存関係を考慮した適切な順序で整理する。各タスクには実装詳細、テスト要件、UI/UX要件を含める。
+
+設計文書に基づいて実装タスクを1日単位の粒度で分割し、1ヶ月単位のフェーズに整理する。各フェーズ毎に個別のタスクファイルを作成し、依存関係を考慮した適切な順序で管理する。
 
 ## 前提条件
+
 - `docs/design/{要件名}/` に設計文書が存在する
 - 設計がユーザによって承認されている（または承認が省略されている）
 - `docs/tasks/` ディレクトリが存在する（なければ作成）
 
 ## 実行内容
 
+**【信頼性レベル指示】**:
+各項目について、元の資料（EARS要件定義書・設計文書含む）との照合状況を以下の信号でコメントしてください：
+
+- 🟢 **青信号**: EARS要件定義書・設計文書を参考にしてほぼ推測していない場合
+- 🟡 **黄信号**: EARS要件定義書・設計文書から妥当な推測の場合
+- 🔴 **赤信号**: EARS要件定義書・設計文書にない推測の場合
+
 1. **設計文書の分析**
    - `docs/design/{要件名}/architecture.md` を確認
    - `docs/design/{要件名}/database-schema.sql` を確認
@@ -17,20 +26,25 @@
    - `docs/design/{要件名}/interfaces.ts` を確認
    - `docs/design/{要件名}/dataflow.md` を確認
 
-2. **タスクの洗い出し**
+2. **既存タスクファイルの確認**
+   - 既存の`docs/tasks/{要件名}-*.md`ファイルを確認
+   - 使用済みタスク番号（TASK-0001形式）を抽出
+   - 新規タスクで重複しない番号を割り当て
+
+3. **タスクの洗い出し**
    - 基盤タスク（DB設定、環境構築など）
    - バックエンドタスク（API実装）
    - フロントエンドタスク（UI実装）
    - 統合タスク（E2Eテストなど）
 
-3. **依存関係の分析**
+4. **依存関係の分析**
    - タスク間の依存関係を明確化
    - 並行実行可能なタスクを識別
    - クリティカルパスを特定
 
-4. **タスクの詳細化**
+5. **タスクの詳細化**
    各タスクに以下を含める：
-   - タスクID（一意の識別子）
+   - タスクID（TASK-0001形式の4桁番号）
    - タスク名
    - タスクタイプ（TDD/DIRECT）
      - **TDD**: コーディング、ビジネスロジック実装、UI実装、テスト実装など開発作業
@@ -46,135 +60,278 @@
      - モバイル対応
      - アクセシビリティ要件
 
-5. **タスクの順序付け**
+6. **タスクの順序付け**
    - 依存関係に基づいて実行順序を決定
    - マイルストーンを設定
    - 並行実行可能なタスクをグループ化
 
-6. **ファイルの作成**
-   - `docs/tasks/{要件名}-tasks.md` として保存
-   - 出力フォーマット例を確認して、出力フォーマット例に沿った情報を記載する
+7. **フェーズ分割とファイル作成**
+   - タスクを1ヶ月程度の期間でフェーズに分割
+   - 各フェーズ毎に個別のタスクファイルを作成
+   - `docs/tasks/{要件名}-overview.md`: 全体概要とフェーズ一覧
+   - `docs/tasks/{要件名}-phase1.md`: フェーズ1の詳細タスク
+   - `docs/tasks/{要件名}-phase2.md`: フェーズ2の詳細タスク
+   - （以下、フェーズ数に応じて継続）
+   - 各タスクを1日単位の粒度で設計
    - 各タスクにチェックボックスを追加してタスクの完了状況を追跡可能にする
-   - 出力フォーマット例を確認して、出力フォーマット例に沿った情報が抜けていたら追加する
 
 ## 出力フォーマット例
 
+### 1. overview.md（全体概要）
+
 ````markdown
-# {要件名} 実装タスク
+# {要件名} 実装タスク全体概要
+
+## プロジェクト概要
+
+- **要件名**: {要件名}
+- **総期間**: {開始日} 〜 {終了予定日}
+- **総工数**: {工数}
+- **総タスク数**: {数}
+
+## フェーズ構成
+
+| フェーズ | 期間 | 主要成果物 | タスク数 | 工数 | ファイル |
+|---------|------|-----------|---------|------|---------|
+| Phase 1: 基盤構築 | 1ヶ月 | 開発環境・DB設定 | 20タスク | 160h | [phase1.md](phase1.md) |
+| Phase 2: コア機能 | 1ヶ月 | 基本API・認証 | 22タスク | 176h | [phase2.md](phase2.md) |
+| Phase 3: UI実装 | 1ヶ月 | 画面・コンポーネント | 25タスク | 200h | [phase3.md](phase3.md) |
+| Phase 4: 統合・最適化 | 2週間 | テスト・性能調整 | 10タスク | 80h | [phase4.md](phase4.md) |
+
+## 既存タスク番号の管理
+
+**既存ファイル確認結果**:
+- 確認したファイル: `docs/tasks/{要件名}-*.md`
+- 使用済みタスク番号: TASK-0001 〜 TASK-0077 (例)
+- 次回開始番号: TASK-0078
+
+## 依存関係
+
+```mermaid
+gantt
+    title プロジェクト全体スケジュール
+    dateFormat  YYYY-MM-DD
+    section Phase 1
+    基盤構築           :phase1, 2024-01-01, 30d
+    section Phase 2
+    コア機能           :phase2, after phase1, 30d
+    section Phase 3
+    UI実装            :phase3, after phase2, 30d
+    section Phase 4
+    統合・最適化       :phase4, after phase3, 14d
+```
+
+## 進捗管理
+
+### 全体進捗
+- [ ] Phase 1: 基盤構築 (0/20)
+- [ ] Phase 2: コア機能 (0/22)
+- [ ] Phase 3: UI実装 (0/25)
+- [ ] Phase 4: 統合・最適化 (0/10)
+
+### マイルストーン
+- [ ] M1: 開発環境完成 (Phase 1完了時)
+- [ ] M2: MVP機能完成 (Phase 2完了時)
+- [ ] M3: UI完成 (Phase 3完了時)
+- [ ] M4: リリース準備完了 (Phase 4完了時)
+
+## リスク管理
+
+| リスク | 影響度 | 発生確率 | 対策 |
+|--------|--------|----------|------|
+| {リスク項目} | 高/中/低 | 高/中/低 | {対策内容} |
+
+## 品質基準
+
+- テストカバレッジ: 90%以上
+- パフォーマンス: 応答時間3秒以内
+- セキュリティ: OWASP Top 10対応
+- アクセシビリティ: WCAG 2.1 AA準拠
+````
+
+### 2. phase*.md（各フェーズ詳細）
+
+````markdown
+# {要件名} Phase 1: 基盤構築
+
+## フェーズ概要
+
+- **期間**: 1ヶ月 (20営業日)
+- **目標**: 開発環境とデータベース基盤の構築
+- **成果物**: 動作する開発環境、データベーススキーマ、CI/CD基盤
+- **担当**: {担当者名}
+
+## 週次計画
+
+### Week 1: 環境構築
+- **目標**: 基本的な開発環境の構築
+- **成果物**: Docker環境、基本設定
 
-## 概要
+### Week 2: データベース設計
+- **目標**: データベーススキーマの実装
+- **成果物**: DB設計、マイグレーション
 
-全タスク数: {数}
-推定作業時間: {時間}
-クリティカルパス: {タスクID列}
+### Week 3: CI/CD構築
+- **目標**: 自動化パイプラインの構築
+- **成果物**: テスト・デプロイ自動化
 
-## タスク一覧
+### Week 4: 基盤テスト・調整
+- **目標**: 基盤の安定化
+- **成果物**: 動作確認済み基盤
 
-### フェーズ1: 基盤構築
+## 日次タスク
 
-#### TASK-001: データベース初期設定
+### Week 1: 環境構築
+
+#### Day 1 (TASK-0001): プロジェクト初期化
 
 - [ ] **タスク完了**
+- **推定工数**: 8時間
 - **タスクタイプ**: DIRECT
-- **要件リンク**: REQ-401
+- **要件リンク**: REQ-001
 - **依存タスク**: なし
 - **実装詳細**:
-  - PostgreSQLのDockerコンテナ設定
-  - 初期スキーマの作成
-  - マイグレーション設定
-- **テスト要件**:
-  - [ ] データベース接続テスト
-  - [ ] スキーマ検証テスト
+  - Node.js/TypeScript環境設定
+  - package.json設定
+  - ESLint/Prettier設定
+  - Git初期化・.gitignore設定
 - **完了条件**:
-  - [ ] データベースが起動している
-  - [ ] 全テーブルが作成されている
+  - [ ] npm run dev で開発サーバーが起動する
+  - [ ] npm run lint でエラーが出ない
+  - [ ] TypeScript設定が正しく動作する
+- **注意事項**: Node.js LTS版を使用すること
 
-#### TASK-002: バックエンド基本設定
+#### Day 2 (TASK-0002): Docker環境構築
 
 - [ ] **タスク完了**
+- **推定工数**: 8時間
 - **タスクタイプ**: DIRECT
-- **要件リンク**: REQ-001, REQ-002
-- **依存タスク**: TASK-001
+- **要件リンク**: REQ-002
+- **依存タスク**: TASK-0001
 - **実装詳細**:
-  - Express/NestJSの初期設定
-  - TypeScript設定
-  - 環境変数設定
-- **テスト要件**:
-  - [ ] サーバー起動テスト
-  - [ ] ヘルスチェックエンドポイントテスト
+  - Dockerfile作成
+  - docker-compose.yml設定
+  - PostgreSQL・Redis設定
+  - 環境変数管理設定
+- **完了条件**:
+  - [ ] docker-compose up で全サービスが起動する
+  - [ ] アプリケーションからDB接続できる
+  - [ ] ホットリロードが動作する
+- **注意事項**: ポート競合に注意すること
 
-### フェーズ2: API実装
+#### Day 3 (TASK-0003): 基本ディレクトリ構造
 
-#### TASK-101: ユーザー認証API
+- [ ] **タスク完了**
+- **推定工数**: 6時間
+- **タスクタイプ**: DIRECT
+- **要件リンク**: REQ-003
+- **依存タスク**: TASK-0002
+- **実装詳細**:
+  - src/ディレクトリ構造作成
+  - テストディレクトリ構造
+  - 設定ファイル配置
+  - README.md作成
+- **完了条件**:
+  - [ ] Clean Architectureに沿った構造
+  - [ ] テストファイルの配置が正しい
+  - [ ] README.mdが充実している
+- **注意事項**: 後から変更しにくい構造のため慎重に設計
+
+#### Day 4 (TASK-0004): ログ・エラーハンドリング基盤
 
 - [ ] **タスク完了**
+- **推定工数**: 8時間
 - **タスクタイプ**: TDD
-- **要件リンク**: REQ-101, REQ-102
-- **依存タスク**: TASK-002
+- **要件リンク**: REQ-004
+- **依存タスク**: TASK-0003
 - **実装詳細**:
-  - JWT認証の実装
-  - ログイン/ログアウトエンドポイント
-  - トークンリフレッシュ機能
+  - Winston/Pinoログライブラリ設定
+  - エラーハンドリングミドルウェア
+  - 構造化ログ設定
+  - ログローテーション設定
 - **テスト要件**:
-  - [ ] 単体テスト: 認証ロジック
-  - [ ] 統合テスト: ログインフロー
-  - [ ] セキュリティテスト: トークン検証
-- **エラーハンドリング**:
-  - [ ] 無効な認証情報
-  - [ ] トークン期限切れ
-  - [ ] レート制限
-
-### フェーズ3: フロントエンド実装
+  - [ ] ログ出力テスト
+  - [ ] エラーハンドリングテスト
+  - [ ] ログレベル制御テスト
+- **完了条件**:
+  - [ ] 各レベルのログが正しく出力される
+  - [ ] エラーが適切にキャッチされる
+  - [ ] 本番環境でセンシティブ情報が出力されない
 
-#### TASK-201: ログイン画面
+#### Day 5 (TASK-0005): 設定管理システム
 
 - [ ] **タスク完了**
+- **推定工数**: 6時間
 - **タスクタイプ**: TDD
-- **要件リンク**: REQ-101
-- **依存タスク**: TASK-101
+- **要件リンク**: REQ-005
+- **依存タスク**: TASK-0004
 - **実装詳細**:
-  - React/Vue/Angularコンポーネント
-  - フォームバリデーション
-  - エラー表示
-- **UI/UX要件**:
-  - [ ] ローディング状態: ボタン無効化 + スピナー
-  - [ ] エラー表示: トースト通知
-  - [ ] モバイル対応: レスポンシブデザイン
-  - [ ] アクセシビリティ: ARIA属性、キーボード操作
+  - 環境別設定ファイル
+  - 設定バリデーション
+  - 機密情報管理
+  - 設定読み込みモジュール
 - **テスト要件**:
-  - [ ] コンポーネントテスト
-  - [ ] E2Eテスト: ログインフロー
-  - [ ] レスポンシブテスト
+  - [ ] 設定読み込みテスト
+  - [ ] 環境別設定テスト
+  - [ ] 設定バリデーションテスト
+- **完了条件**:
+  - [ ] 環境変数が正しく読み込まれる
+  - [ ] 不正な設定でエラーになる
+  - [ ] 機密情報が適切に管理される
 
-### フェーズ4: 統合・最適化
+### Week 2: データベース設計
 
-#### TASK-301: E2Eテストスイート
+#### Day 6 (TASK-0006): データベース接続基盤
 
 - [ ] **タスク完了**
+- **推定工数**: 8時間
 - **タスクタイプ**: TDD
-- **要件リンク**: 全要件
-- **依存タスク**: TASK-201
+- **要件リンク**: REQ-401
+- **依存タスク**: TASK-0005
 - **実装詳細**:
-  - Cypress/Playwrightセットアップ
-  - 主要ユーザーフローのテスト
-  - CI/CD統合
+  - TypeORM/Prisma設定
+  - 接続プール設定
+  - マイグレーション基盤
+  - データベースモニタリング
+- **テスト要件**:
+  - [ ] 接続プールテスト
+  - [ ] 接続障害処理テスト
+  - [ ] トランザクション管理テスト
+- **完了条件**:
+  - [ ] データベース接続が安定している
+  - [ ] 接続プールが適切に動作する
+  - [ ] マイグレーションコマンドが動作する
 
-## 実行順序
+{...続き、Day 7-20まで同様の形式で記載...}
 
-```mermaid
-gantt
-    title タスク実行スケジュール
-    dateFormat  YYYY-MM-DD
-    section 基盤
-    TASK-001           :a1, 2024-01-01, 1d
-    TASK-002           :a2, after a1, 1d
-    section API
-    TASK-101           :b1, after a2, 2d
-    section フロントエンド
-    TASK-201           :c1, after b1, 2d
-    section 統合
-    TASK-301           :d1, after c1, 1d
-```
+## フェーズ完了基準
+
+- [ ] 全タスクが完了している (20/20)
+- [ ] 開発環境が安定して動作する
+- [ ] データベーススキーマが完成している
+- [ ] CI/CDパイプラインが動作する
+- [ ] 基盤コードのテストカバレッジが90%以上
+- [ ] セキュリティチェックが完了している
+- [ ] ドキュメントが整備されている
+
+## 次フェーズへの引き継ぎ事項
+
+- 開発環境の利用方法
+- データベーススキーマの詳細
+- CI/CDの運用方法
+- 設定項目の一覧
+- トラブルシューティング情報
+
+## 振り返り
+
+### 計画との差異
+- {計画と実際の差異を記録}
+
+### 学習事項
+- {技術的な学習事項を記録}
+
+### 改善点
+- {次フェーズで改善すべき点を記録}
 ````
 
 ## サブタスクテンプレート
@@ -200,8 +357,31 @@ gantt
 ```
 
 ## 実行後の確認
-- 作成したファイルのパスを表示
-- タスクの総数と推定時間を表示
-- クリティカルパスを強調表示
+
+- 作成したファイルの一覧を表示
+  - `docs/tasks/{要件名}-overview.md`: 全体概要とフェーズ一覧
+  - `docs/tasks/{要件名}-phase1.md`: フェーズ1詳細
+  - `docs/tasks/{要件名}-phase2.md`: フェーズ2詳細
+  - （以下、フェーズ数に応じて継続）
+- 各フェーズの概要とタスク数を表示
+- 全体スケジュールと依存関係を表示
+- プロジェクト期間と総工数を報告
+- **既存タスク番号の確認結果を表示**
+  - 既存ファイルから抽出した使用済み番号
+  - 新規タスクで使用開始する番号
+  - 重複なく連続した番号の割り当て確認
 - ユーザに実装開始の確認を促すメッセージを表示
-```
+
+## ファイル間リンクの確認
+
+- overview.mdから各phase*.mdへのリンクが正しく設定されていることを確認
+- 各フェーズファイル内のタスク依存関係が正しく記載されていることを確認
+- **全タスクIDがTASK-0001形式の4桁で統一されていることを確認**
+- マイルストーンとフェーズ完了基準が明確に定義されていることを確認
+
+## タスク番号管理の注意事項
+
+- 既存ファイルがある場合は必ずGrepツールで使用済み番号を確認
+- TASK-0001からTASK-9999まで最大9999タスクをサポート
+- 番号の重複や欠番が発生しないよう注意深く管理
+- 複数のフェーズファイルにまたがってもタスク番号は連続で割り当て
diff --git a/commands/tdd-green.md b/commands/tdd-green.md
index 4815156..ca6c43c 100644
--- a/commands/tdd-green.md
+++ b/commands/tdd-green.md
@@ -1,4 +1,4 @@
-# TDD Greenフェーズ（最小限の実装）
+# TDD Greenフェーズ（実装）
 
 TDDのGreenフェーズを実行します。
 
@@ -8,7 +8,7 @@ TDDのGreenフェーズを実行します。
 
 **Taskツール実行**: `/tdd-load-context` でTDD関連ファイルの読み込みとコンテキスト準備を実行
 
-読み込み完了後、準備されたコンテキスト情報を基にGreenフェーズ（最小実装）の作業を開始します。
+読み込み完了後、準備されたコンテキスト情報を基にGreenフェーズ（実装）の作業を開始します。
 
 **テスト実行時はTaskツールを利用する**
 
@@ -22,19 +22,23 @@ TDDのGreenフェーズを実行します。
 
 ## 目標
 
-Redフェーズで作成したテストを通すための**最小限の実装**を行ってください。
+Redフェーズで作成したテストを通すための**実装**を行ってください。
 
 ## 実装の原則
 
 - **テストが確実に通ること最優先**
 - コードの美しさは二の次（次のRefactorフェーズで改善）
 - 「とりあえず動く」レベルでOK
-- ハードコーディングでも構わない
 - 複雑なロジックは後回し、シンプルな実装を心がける
 - テストがなかなか通らないときは、Taskツールを使用して失敗原因を調べてから修正の計画を立てて実装する
 - 既存のテストがエラーになった場合は仕様を元に適切に修正する
-- NEVER: 必要なテストのスキップ
-- NEVER: 必要なテストの削除
+- **モック使用の制限**: テストコード以外でモックを記述しない（実装コードは実際のロジックを書く）
+- **ファイルサイズ管理**: 実装ファイルが800行を超えた時点でファイル分割を検討する
+- NEVER: 必要なテストのスキップ禁止
+- NEVER: 必要なテストの削除禁止
+- NEVER: 実装コード内でのモック・スタブの記述禁止
+- NEVER: 実装コード内でDBに代わるインメモリーストレージの利用禁止
+- NEVER: 実装コード内でDB操作の省略禁止
 
 ## 実装時の日本語コメント要件
 
@@ -106,6 +110,7 @@ try {
 ```
 
 ## 実装例
+
 ```javascript
 /**
  * 【機能概要】: JSONファイルパスを検証し、有効/無効なパスを分類する
@@ -134,9 +139,11 @@ function {{function_name}}(input) {
    - 【シンプル実装】: 複雑なアルゴリズムは後のリファクタで追加
    - 【可読性重視】: 現段階では理解しやすさを最優先
 3. **ファイルサイズを意識した実装**
-   - 【モジュール設計】: 将来的に500行未満になるよう機能を適切に分離
+   - 【800行制限】: 実装ファイルが800行を超えた時点で分割を検討
+   - 【モジュール設計】: 機能単位でファイルを適切に分離
    - 【関数分割】: 長大な関数は小さな単位に分割して実装
    - 【責任境界】: 各ファイルの責任範囲を明確にして実装
+   - 【分割戦略】: 機能・レイヤー・ドメインでファイルを分離
 4. **コード品質基準の考慮**
    - 【静的解析対応】: lintやtypecheckでエラーが出ない実装を心がける
    - 【フォーマット統一】: プロジェクトの既存フォーマットに合わせた実装
@@ -147,6 +154,11 @@ function {{function_name}}(input) {
 6. **エラーハンドリングも最小限**
    - 【必要最小限】: テストで要求される部分のみ実装
    - 【将来拡張可能】: リファクタ段階で詳細なエラー処理を追加予定
+7. **モック使用の制限**
+   - 【実装コード制限】: 実装コード内でモック・スタブを使用しない
+   - 【テストコード限定】: モックはテストコード内でのみ使用
+   - 【実際のロジック実装】: 実装コードは実際の処理を記述する
+   - 【依存関係注入】: 必要に応じて依存性注入パターンで実装
 
 ## 提供してください
 
@@ -154,6 +166,8 @@ function {{function_name}}(input) {
 2. **テスト実行結果**: Taskツールを使用して実際にテストが通ることの確認
 3. **実装の説明**: どのような考えで実装したか（日本語コメントとの対応関係）
 4. **課題の特定**: 現在の実装の問題点（リファクタ対象の明確化）
+5. **ファイルサイズチェック**: 実装ファイルの行数確認（800行超過時の分割計画）
+6. **モック使用確認**: 実装コードにモック・スタブが含まれていないことの確認
 
 実装完了後、以下を実行してください：
 
@@ -183,6 +197,8 @@ function {{function_name}}(input) {
 - リファクタ箇所: 明確に特定可能
 - 機能的問題: なし
 - コンパイルエラー: なし
+- ファイルサイズ: 800行以下または分割計画が明確
+- モック使用: 実装コードにモック・スタブが含まれていない
 
 ⚠️ 要改善:
 - テストの一部が失敗（Taskツールで検出）
@@ -190,6 +206,8 @@ function {{function_name}}(input) {
 - リファクタ方針が不明
 - 機能に懸念がある
 - コンパイルエラーが存在
+- ファイルサイズが800行を超過し分割計画が不明
+- 実装コードにモック・スタブが含まれている
 ```
 
 ## TODO更新パターン
diff --git a/commands/tdd-load-context.md b/commands/tdd-load-context.md
index 457573d..ec3dd56 100644
--- a/commands/tdd-load-context.md
+++ b/commands/tdd-load-context.md
@@ -7,41 +7,37 @@ TDD開発に必要なファイルを効率的に読み込み、開発コンテ
 以下のTaskツールによる並列読み込みを実行します：
 
 ```
-Taskツールで以下のファイルを並列読み込み:
-
-1. TDDメモファイルの確認
-   - `docs/implements/{{task_id}}/{feature_name}-memo.md`
+1. 【読み込み】TDDメモファイルの確認
+   - Readツール: `docs/implements/{{task_id}}/{feature_name}-memo.md`
    - 既存の開発履歴、フェーズ情報、検証結果を把握
 
-2. 要件定義文書の確認  
-   - `docs/implements/{{task_id}}/{feature_name}-requirements.md`
+2. 【読み込み】要件定義文書の確認  
+   - Readツール: `docs/implements/{{task_id}}/{feature_name}-requirements.md`
    - 機能仕様、入出力、制約条件を把握
 
-3. テストケース定義の確認
-   - `docs/implements/{{task_id}}/{feature_name}-testcases.md` 
+3. 【読み込み】テストケース定義の確認
+   - Readツール: `docs/implements/{{task_id}}/{feature_name}-testcases.md` 
    - 予定テストケース、分類、期待値を把握
 
-4. プロジェクト設計文書の確認（存在する場合）
-   - `docs/spec/{feature_name}-requirements.md` (EARS要件定義書)
-   - `docs/design/{feature_name}/architecture.md`
-   - `docs/design/{feature_name}/interfaces.ts`
-   - `docs/design/{feature_name}/api-endpoints.md`
-   - `docs/design/{feature_name}/database-schema.sql`
-   - `docs/design/{feature_name}/dataflow.md`
-
-5. プロジェクト構造・ライブラリの確認
-   - `package.json` - 利用可能ライブラリの把握
-   - 既存テストファイル構造の確認
-   - 類似機能の実装パターン調査
-
-6. タスク管理文書の確認
-   - `docs/tasks/{要件名}-tasks.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` の存在確認
+   - 見つかったファイルパスを記録（読み込みは実行せず）
 ```
 
 ## 読み込み結果の整理
 
-Taskツールによる並列読み込み完了後、以下の形式で情報を整理します：
+読み込み・探索完了後、以下の形式で情報を整理します：
 
 ### 📋 開発コンテキスト情報
 
@@ -61,21 +57,12 @@ Taskツールによる並列読み込み完了後、以下の形式で情報を
 - **制約条件**: [パフォーマンス・セキュリティ・技術制約]
 - **参照EARS要件**: [REQ-XXX, NFR-XXX等の要件ID]
 
-### 🧪 テスト情報
-- **予定テストケース総数**: [数]個
-- **テスト分類**:
-  - 正常系: [数]個
-  - 異常系: [数]個  
-  - エッジケース: [数]個
-- **実装済みテスト**: [数]個 (実装率: [%])
-- **テスト成功率**: [通過数]/[実装数] ([%])
-
 ### 🔧 技術・実装情報
 - **使用言語**: [JavaScript/TypeScript等]
 - **テストフレームワーク**: [Jest/Mocha等]
-- **利用可能ライブラリ**: [主要ライブラリ一覧]
-- **既存実装パターン**: [参考にする既存実装]
-- **命名規則**: [プロジェクトの命名規則]
+- **関連ファイル**: [探索で見つかった関連ファイルパス一覧]
+- **設計文書パス**: [見つかった設計文書のパス一覧]
+- **類似実装パス**: [参考にできる既存実装のファイルパス]
 
 ### 📈 進捗・品質情報
 - **全体タスク進捗**: [完了数]/[総数] ([%])
@@ -106,16 +93,17 @@ Taskツールによる並列読み込み完了後、以下の形式で情報を
 
 開発コンテキストの準備を行います：
 
-**Taskツール実行**: `/tdd-load-context` でTDD関連ファイルの読み込みとコンテキスト準備を実行
+**Taskツール実行**: `/tdd-load-context` でTDD関連ファイルの読み込み・探索とコンテキスト準備を実行
 
 読み込み完了後、準備されたコンテキスト情報を基に{現在のフェーズ}の作業を開始します。
 ```
 
 ## 効果
 
-- **効率化**: 複数ファイルの並列読み込みによる時間短縮
+- **効率化**: メモ・要件・テストケースは読み込み、その他は探索のみで時間短縮
 - **一貫性**: 全TDDフェーズで統一されたコンテキスト準備
 - **品質向上**: 必要情報の読み込み漏れ防止
-- **保守性**: ファイル読み込みロジックの一元管理
+- **保守性**: ファイル読み込み・探索ロジックの一元管理
+- **軽量化**: 関連ファイルは特定のみで、必要に応じて個別に読み込み可能
 
 このタスクにより、TDD開発の各フェーズで必要な情報を効率的に準備できます。
\ No newline at end of file
diff --git a/commands/tdd-red.md b/commands/tdd-red.md
index e1fed85..5775413 100644
--- a/commands/tdd-red.md
+++ b/commands/tdd-red.md
@@ -14,6 +14,13 @@ TDDのRedフェーズを実行します。
 
 **【対象テストケース】**: {{test_case_name}}
 
+## テストケース追加目標数
+
+**テストケース追加目標数**: 10以上（利用可能なテストケースが10未満の場合は全て追加）
+
+未実装のテストケースから10個以上のテストケースを選択して実装してください。利用可能なテストケースが10個未満の場合は、利用可能な全てのテストケースを実装対象とします。
+既にテストケースが実装済みの場合はテストケース定義に書かれているテストケースからテストを追加します。
+
 ## 信頼性レベル指示
 
 テストコード作成時には、各テストケースの内容について元の資料との照合状況を以下の信号でコメントしてください：
@@ -163,6 +170,7 @@ docs/implements/{{task_id}}/{feature_name}-memo.mdファイルの形式：
 
 ## 関連ファイル
 
+- 元タスクファイル: `docs/tasks/{taskファイルのパス}.md`
 - 要件定義: `docs/implements/{{task_id}}/{feature_name}-requirements.md`
 - テストケース定義: `docs/implements/{{task_id}}/{feature_name}-testcases.md`
 - 実装ファイル: `[実装ファイルのパス]`
diff --git a/commands/tdd-refactor.md b/commands/tdd-refactor.md
index b1cb1ef..04f44c6 100644
--- a/commands/tdd-refactor.md
+++ b/commands/tdd-refactor.md
@@ -42,6 +42,9 @@ Greenフェーズで実装されたコードを以下の観点で改善してく
 - 依存関係の整理
 - モジュール化の検討
 
+- NEVER: 実装コード内でのモック・スタブの記述
+- NEVER: 実装コード内でDBに代わるインメモリーストレージの利用
+
 ### 4. ファイルサイズの最適化
 
 - ファイルサイズが500行未満になるよう分割・最適化
diff --git a/commands/tdd-requirements.md b/commands/tdd-requirements.md
index 464e073..bd03082 100644
--- a/commands/tdd-requirements.md
+++ b/commands/tdd-requirements.md
@@ -81,7 +81,7 @@ TDD開発を始めます。以下の機能について要件を整理してく
 
 整理後、以下を実行してください：
 
-1. 要件定義書をdoc/implementation/{feature_name}-requirements.mdに保存（既存ファイルがある場合は追記）
+1. 要件定義書をdocs/implements/{{task_id}}/{feature_name}-requirements.mdに保存（既存ファイルがある場合は追記）
 2. TODOステータスを更新（要件定義完了をマーク）
 3. **品質判定**: 要件の品質を以下の基準で判定
    - 要件が明確で曖昧さがない
diff --git a/commands/tdd-testcases.md b/commands/tdd-testcases.md
index 8e0f6b8..25d5500 100644
--- a/commands/tdd-testcases.md
+++ b/commands/tdd-testcases.md
@@ -139,7 +139,7 @@ afterEach(() => {
 
 すべて洗い出したら以下を実行してください：
 
-1. テストケース一覧をdoc/implementation/{feature_name}-testcases.mdに保存（既存ファイルがある場合は追記）
+1. テストケース一覧をdocs/implements/{{task_id}}/{feature_name}-testcases.mdに保存（既存ファイルがある場合は追記）
 2. TODOステータスを更新（テストケース洗い出し完了をマーク）
 3. **品質判定**: テストケースの品質を以下の基準で判定
    - テストケース分類: 正常系・異常系・境界値が網羅されている
diff --git a/commands/tdd-verify-complete.md b/commands/tdd-verify-complete.md
index df2d6e5..3ec8275 100644
--- a/commands/tdd-verify-complete.md
+++ b/commands/tdd-verify-complete.md
@@ -6,21 +6,31 @@ TDD開発でテストケースの実装が完全に完了しているかを検
 
 リファクタリング後に、予定していたテストケースがすべて実装されているかを確認し、実装漏れを防ぎます。
 
+## 重要な原則
+
+**⚠️ この工程では修正を行わない**
+- この検証フェーズではコードやテストの修正は一切行わない
+- 問題を発見した場合は内容をmemoファイルに記載する
+- 修正作業は後の工程（次のTDDサイクルや別のタスク）に委ねる
+- 検証・記録・報告に専念する
+
 ## 検証手順
 
 ### 1. 既存テストのグリーン状態確認
 
 - **必須**: 全ての既存テストが成功していることを確認
 - `npm test` または `jest` を実行してテスト結果を確認
-- テスト失敗がある場合は先に修正が必要
-- すべてのテストがグリーンであることを確認してから次のステップに進む
+- **テスト失敗がある場合**: memoファイルに記載し、後の工程で修正対応
+- **この工程では修正禁止**: テスト失敗を発見してもここでは修正しない
+- テスト状態を記録し、次のステップに進む
+
+### 2. 事前準備
+
+検証コンテキストの準備を行います：
 
-### 2. TDDメモファイルと要件定義文書の確認
-- `doc/implementation/{test_case_name}-memo.md` を確認（メモファイルが存在する場合）
-- `doc/implementation/{feature_name}-requirements.md` を確認
-- `doc/implementation/{feature_name}-testcases.md` を確認
-- `doc/todo.md` を確認して対象タスクの現在のステータスを把握
-- 予定していたテストケース数と内容を把握
+**Taskツール実行**: `/tdd-load-context` でTDD関連ファイルの読み込みとコンテキスト準備を実行
+
+読み込み完了後、準備されたコンテキスト情報を基にテストケース完全性検証を開始します。
 
 ### 2. 実装済みテストケースの確認
 
@@ -107,14 +117,16 @@ TDD開発でテストケースの実装が完全に完了しているかを検
 
 ### 5. 検証結果のメモファイル記録とTODO.md更新
 
-#### メモファイルへの追記
-検証完了後、以下の情報を `doc/implementation/{test_case_name}-memo.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`
 
@@ -133,9 +145,25 @@ TDD開発でテストケースの実装が完全に完了しているかを検
 ### 品質保証
 [品質確保で重要だった観点]
 
-## ⚠️ 注意点（該当時のみ）
+## ⚠️ 注意点・修正が必要な項目（該当時のみ）
 [実装時の重要な注意事項や未完了項目]
 
+### 🔧 後工程での修正対象
+#### テスト失敗
+- [失敗しているテストケース名]
+- **失敗内容**: [具体的な失敗内容]
+- **修正方針**: [推奨される修正方法]
+
+#### 実装不足
+- [未実装の機能や要件]
+- **不足内容**: [具体的な不足内容]
+- **対応方針**: [推奨される対応方法]
+
+#### 品質改善
+- [品質向上が必要な箇所]
+- **改善内容**: [具体的な改善内容]
+- **改善方針**: [推奨される改善方法]
+
 ---
 *既存のメモ内容から重要な情報を統合し、重複・詳細な経過記録は削除*
 ```
@@ -147,11 +175,11 @@ TDD開発でテストケースの実装が完全に完了しているかを検
 4. **再利用重視**: 今後の開発で参考になる情報を優先して残す
 5. **関連情報重視**: 仕様情報などの情報は優先して残す
 
-#### TODO.md完了マーク自動更新
+#### 元タスクファイル完了マーク自動更新
 
-検証が完了した場合、以下の手順でTODO.mdを自動更新：
+検証が完了した場合、以下の手順で元タスクファイルを自動更新：
 
-1. **完了タスクの特定**: 現在のTDD開発対象タスクを特定
+1. **完了タスクの特定**: 現在のTDD開発対象タスクを元タスクファイルから特定
 2. **完了マーク追加**: 該当タスクに `✅ **完了**` マークを追加
 3. **完了理由記載**: `(TDD開発完了 - [テスト数]テストケース全通過)` を追記
 4. **サブタスク更新**: 関連するサブタスクにも `[x]` チェックマークを追加
@@ -182,32 +210,37 @@ TDD開発でテストケースの実装が完全に完了しているかを検
 ```
 
 **メモファイル記録**: 検証結果をメモファイルに自動追記する。
-**TODO.md更新**: 完了したタスクに✅完了マークを自動追加する。
+**元タスクファイル更新**: 完了したタスクに✅完了マークを自動追加する。
 
 #### 実装不足がある場合
 
-以下のメッセージを提供し、追加実装を促す：
+以下のメッセージを提供し、状況を記録する：
 
 ```
 ⚠️ テストケース実装不足を検出
 
 未実装テストケース（[数]個）があります。
-完全な品質保証のため、以下の追加実装をお勧めします：
+以下の内容をmemoファイルに記録しました：
 
 [未実装テストケースのリスト]
 
-追加実装を行いますか？それとも現状で次のステップに進みますか？
+【重要】この工程では修正を行いません。
+修正が必要な内容はmemoファイルに記載され、後の工程で対応されます。
+
+現状の記録を完了し、次のステップに進みます。
 ```
 
-**メモファイル記録**: 実装不足の検証結果もメモファイルに追記する。
-**TODO.md更新**: 実装不足の場合でも、部分完了したタスクがあれば適切にマークする。
+**メモファイル記録**: 実装不足の検証結果と修正方針をメモファイルに詳細記録する。
+**元タスクファイル更新**: 実装不足の場合でも、部分完了したタスクがあれば適切にマークする。
+**修正作業禁止**: この工程では一切の修正作業を行わない。
 
 ## 検証対象ファイル
 
 ### 確認すべきドキュメント
-- `doc/todo.md` - プロジェクト全体のタスク完了状況（完了マーク更新対象）
-- `doc/implementation/{feature_name}-requirements.md`
-- `doc/implementation/{feature_name}-testcases.md`
+
+- **元タスクファイル**: `docs/tasks/{taskファイルのパス}.md` - プロジェクト全体のタスク完了状況（完了マーク更新対象）
+- `docs/implements/{{task_id}}/{feature_name}-requirements.md`
+- `docs/implements/{{task_id}}/{feature_name}-testcases.md`
 
 ### 確認すべきテストファイル
 
@@ -349,7 +382,8 @@ TDD開発でテストケースの実装が完全に完了しているかを検
 ❌ 未実装テストケース:
 [未実装テストケースの詳細リスト]
 
-🤔 要件充実度向上のため追加実装を行いますか？
+📝 **修正内容をmemoファイルに記録済み**
+後の工程で対応予定です。この工程では修正を行いません。
 ```
 
 この検証により、TDD開発の品質と完全性を確保します。