speccrew 0.5.9 → 0.5.11

package/docs/GETTING-STARTED.ja.md

@@ -32,7 +32,7 @@ npm install -g speccrew
 speccrew init --ide qoder
 ```
 
-サポートされているIDE：`qoder`、`cursor`、`claude`、`codex`
+サポートされているIDE:`qoder`、`cursor`、`claude`、`codex`
 
 ### 初期化後のディレクトリ構造
 
@@ -46,7 +46,7 @@ speccrew init --ide qoder
 │   ├── iterations/      # 進行中のイテレーション
 │   ├── iteration-archives/  # アーカイブされたイテレーション
 │   └── knowledges/      # ナレッジベース
-│       ├── base/        # 基本情報（診断レポート、技術的負債）
+│       ├── base/        # 基本情報(診断レポート、技術的負債)
 │       ├── bizs/        # ビジネスナレッジベース
 │       └── techs/       # テクニカルナレッジベース
 ```
@@ -62,7 +62,82 @@ speccrew init --ide qoder
 
 ---
 
-## 2. ワークフロー概要
+## 2. インストール後5分でクイックスタート
+
+`speccrew init` を実行した後、以下の手順で迅速に作業状態に入ることができます:
+
+### ステップ1: IDEを選択
+
+| IDE | 初期化コマンド | 適用シーン |
+|-----|-----------|----------|
+| **Qoder**(推奨) | `speccrew init --ide qoder` | 完全なエージェントオーケストレーション、並列ワーカー |
+| **Cursor** | `speccrew init --ide cursor` | Composerベースのワークフロー |
+| **Claude Code** | `speccrew init --ide claude` | CLIファースト開発 |
+| **Codex** | `speccrew init --ide codex` | OpenAIエコシステム統合 |
+
+### ステップ2: ナレッジベースの初期化(推奨)
+
+既存のソースコードがあるプロジェクトの場合、まずナレッジベースを初期化して、エージェントがコードベースを理解できるようにすることを推奨します:
+
+```
+@speccrew-team-leader テクニカルナレッジベースを初期化
+```
+
+次に:
+
+```
+@speccrew-team-leader ビジネスナレッジベースを初期化
+```
+
+### ステップ3: 最初のタスクを開始
+
+```
+@speccrew-product-manager 新しい要件があります:[機能要件を説明]
+```
+
+> **ヒント**:何をすべきか不明な場合は、直接 `@speccrew-team-leader 開始を支援して` と言ってください — Team Leaderが自動的にプロジェクト状態を検出してガイドします。
+
+---
+
+## 3. クイック決定ツリー
+
+何をすべきか不明ですか?あなたのシナリオを見つけてください:
+
+- **新しい機能要件がある**
+  → `@speccrew-product-manager 新しい要件があります:[機能要件を説明]`
+
+- **既存プロジェクトの知識をスキャンしたい**
+  → `@speccrew-team-leader テクニカルナレッジベースを初期化`
+  → 次に:`@speccrew-team-leader ビジネスナレッジベースを初期化`
+
+- **以前の作業を継続したい**
+  → `@speccrew-team-leader 現在の進捗は何ですか?`
+
+- **システムの健康状態をチェックしたい**
+  → ターミナルで実行:`speccrew doctor`
+
+- **何をすべきか不明**
+  → `@speccrew-team-leader 開始を支援して`
+  → Team Leaderが自動的にプロジェクト状態を検出してガイドします
+
+---
+
+## 4. エージェントクイックリファレンス
+
+| 役割 | エージェント | 責任 | コマンド例 |
+|------|-------|------|----------|
+| チームリーダー | `@speccrew-team-leader` | プロジェクトナビゲーション、ナレッジベース初期化、状態確認 | "開始を支援して" |
+| プロダクトマネージャー | `@speccrew-product-manager` | 要件分析、PRD生成 | "新しい要件があります:..." |
+| 機能デザイナー | `@speccrew-feature-designer` | 機能分析、仕様設計、API契約 | "イテレーションXの機能設計を開始" |
+| システムデザイナー | `@speccrew-system-designer` | アーキテクチャ設計、プラットフォーム詳細設計 | "イテレーションXのシステム設計を開始" |
+| システム開発者 | `@speccrew-system-developer` | 開発調整、コード生成 | "イテレーションXの開発を開始" |
+| テストマネージャー | `@speccrew-test-manager` | テスト計画、ケース設計、実行 | "イテレーションXのテストを開始" |
+
+> **ヒント**:すべてのエージェントを覚える必要はありません。`@speccrew-team-leader` と話すだけで、リクエストを適切なエージェントにルーティングします。
+
+---
+
+## 5. ワークフロー概要
 
 ### 完全フロー図
 
@@ -83,52 +158,52 @@ flowchart LR
 
 ### 核心原則
 
-1. **フェーズ依存関係**：各フェーズの成果物は次のフェーズの入力
-2. **チェックポイント確認**：各フェーズに確認ポイントがあり、ユーザー確認後に次のフェーズに進む
-3. **ナレッジベース駆動**：ナレッジベースは全体を通して各フェーズにコンテキストを提供
+1. **フェーズ依存関係**:各フェーズの成果物は次のフェーズの入力
+2. **チェックポイント確認**:各フェーズに確認ポイントがあり、ユーザー確認後に次のフェーズに進む
+3. **ナレッジベース駆動**:ナレッジベースは全体を通して各フェーズにコンテキストを提供
 
 ---
 
-## 3. ステップ0：ナレッジベース初期化
+## 6. ステップ0:ナレッジベース初期化
 
 正式なエンジニアリングフローを開始する前に、プロジェクトナレッジベースを初期化する必要があります。
 
-### 3.1 テクニカルナレッジベース初期化
+### 6.1 テクニカルナレッジベース初期化
 
-**会話例**：
+**会話例**:
 ```
 @speccrew-team-leader テクニカルナレッジベースを初期化
 ```
 
-**3段階フロー**：
+**3段階プロセス**:
 1. プラットフォーム検出 — プロジェクト内の技術プラットフォームを識別
-2. 技術文書生成 — 各プラットフォームの技術仕様文書を生成
+2. 技術ドキュメント生成 — 各プラットフォームの技術仕様ドキュメントを生成
 3. インデックス生成 — ナレッジベースインデックスを構築
 
-**成果物**：
+**成果物**:
 ```
 speccrew-workspace/knowledges/techs/{platform-id}/
-├── tech-stack.md          # テクノロジースタック定義
+├── tech-stack.md          # 技術スタック定義
 ├── architecture.md        # アーキテクチャ規約
 ├── dev-spec.md            # 開発規約
 ├── test-spec.md           # テスト規約
 └── INDEX.md               # インデックスファイル
 ```
 
-### 3.2 ビジネスナレッジベース初期化
+### 6.2 ビジネスナレッジベース初期化
 
-**会話例**：
+**会話例**:
 ```
 @speccrew-team-leader ビジネスナレッジベースを初期化
 ```
 
-**4段階フロー**：
-1. 機能リスト — コードをスキャンしてすべての機能を識別
+**4段階プロセス**:
+1. 機能インベントリ — コードをスキャンしてすべての機能特性を識別
 2. 機能分析 — 各機能のビジネスロジックを分析
-3. モジュール要約 — モジュール別に機能を要約
+3. モジュール要約 — モジュール別に機能を集約
 4. システム要約 — システムレベルのビジネス概要を生成
 
-**成果物**：
+**成果物**:
 ```
 speccrew-workspace/knowledges/bizs/
 ├── {platform-type}/
@@ -139,78 +214,78 @@ speccrew-workspace/knowledges/bizs/
 
 ---
 
-## 4. フェーズ別会話ガイド
+## 7. フェーズ別会話ガイド
 
-### 4.1 フェーズ1：要件分析（Product Manager）
+### 7.1 フェーズ1:要件分析(Product Manager)
 
-**起動方法**：
+**開始方法**:
 ```
-@speccrew-product-manager 新しい要件があります：[要件を説明]
+@speccrew-product-manager 新しい要件があります:[要件を説明]
 ```
 
-**エージェントワークフロー**：
+**エージェントワークフロー**:
 1. システム概要を読み込んで既存モジュールを理解
 2. ユーザー要件を分析
-3. 構造化されたPRD文書を生成
+3. 構造化されたPRDドキュメントを生成
 
-**成果物**：
+**成果物**:
 ```
-iterations/{シーケンス}-{タイプ}-{名前}/01.product-requirement/
-├── [feature-name]-prd.md           # 製品要件文書
-└── [feature-name]-bizs-modeling.md # ビジネスモデリング（複雑な要件の場合）
+iterations/{番号}-{タイプ}-{名前}/01.product-requirement/
+├── [feature-name]-prd.md           # 製品要件ドキュメント
+└── [feature-name]-bizs-modeling.md # ビジネスモデリング(複雑な要件の場合)
 ```
 
-**確認ポイント**：
-- [ ] 要件の説明がユーザーの意図を正確に反映しているか
-- [ ] ビジネスルールが完全か
-- [ ] 既存システムとの統合ポイントが明確か
-- [ ] 受け入れ基準が測定可能か
+**確認ポイント**:
+- [ ] 要件説明はユーザーの意図を正確に反映しているか
+- [ ] ビジネスルールは完全か
+- [ ] 既存システムとの統合ポイントは明確か
+- [ ] 受け入れ基準は測定可能か
 
 ---
 
-### 4.2 フェーズ2：機能設計（Feature Designer）
+### 7.2 フェーズ2:機能設計(Feature Designer)
 
-**起動方法**：
+**開始方法**:
 ```
 @speccrew-feature-designer 機能設計を開始
 ```
 
-**エージェントワークフロー**：
-1. 確認済みのPRD文書を自動検出
+**エージェントワークフロー**:
+1. 確認済みのPRDドキュメントを自動配置
 2. ビジネスナレッジベースをロード
-3. 機能設計を生成（UIワイヤーフレーム、インタラクションフロー、データ定義、API契約を含む）
-4. 複数のPRDがある場合、タスクワーカーで並列設計
+3. 機能設計を生成(UIワイヤーフレーム、インタラクションフロー、データ定義、API契約を含む)
+4. 複数のPRDがある場合、Task Workerを使用して並列設計
 
-**成果物**：
+**成果物**:
 ```
 iterations/{iter}/02.feature-design/
-└── [feature-name]-feature-spec.md  # 機能設計文書
+└── [feature-name]-feature-spec.md  # 機能設計ドキュメント
 ```
 
-**確認ポイント**：
+**確認ポイント**:
 - [ ] すべてのユーザシナリオがカバーされているか
-- [ ] インタラクションフローが明確か
-- [ ] データフィールド定義が完全か
-- [ ] 例外処理が適切か
+- [ ] インタラクションフローは明確か
+- [ ] データフィールド定義は完全か
+- [ ] 例外処理は完善か
 
 ---
 
-### 4.3 フェーズ3：システム設計（System Designer）
+### 7.3 フェーズ3:システム設計(System Designer)
 
-**起動方法**：
+**開始方法**:
 ```
 @speccrew-system-designer システム設計を開始
 ```
 
-**エージェントワークフロー**：
-1. Feature SpecとAPI契約を検出
-2. テクニカルナレッジベース（各エンドのテクノロジースタック、アーキテクチャ、規約）をロード
-3. **チェックポイントA**：フレームワーク評価 — 技術ギャップを分析、新しいフレームワークを推奨（必要に応じて）、ユーザー確認を待機
+**エージェントワークフロー**:
+1. Feature SpecとAPI Contractを配置
+2. テクニカルナレッジベースをロード(各プラットフォームの技術スタック、アーキテクチャ、規約)
+3. **チェックポイントA**:フレームワーク評価 — 技術ギャップを分析、新しいフレームワークを推奨(必要に応じて)、ユーザー確認を待機
 4. DESIGN-OVERVIEW.mdを生成
-5. タスクワーカーで各エンド設計を並列ディスパッチ（フロントエンド/バックエンド/モバイル/デスクトップ）
-6. **チェックポイントB**：共同確認 — すべてのプラットフォーム設計の要約を表示、ユーザー確認を待機
+5. Task Workerを使用して各プラットフォームの設計を並列配信(フロントエンド/バックエンド/モバイル/デスクトップ)
+6. **チェックポイントB**:合同確認 — すべてのプラットフォーム設計の概要を表示、ユーザー確認を待機
 
-**成果物**：
+**成果物**:
 ```
 iterations/{iter}/03.system-design/
 ├── DESIGN-OVERVIEW.md              # 設計概要
@@ -219,29 +294,29 @@ iterations/{iter}/03.system-design/
 │   └── {module}-design.md          # 擬似コードレベルモジュール設計
 ```
 
-**確認ポイント**：
-- [ ] 擬似コードが実際のフレームワーク構文を使用しているか
-- [ ] クロスエンドAPI契約が一貫しているか
-- [ ] エラー処理戦略が統一されているか
+**確認ポイント**:
+- [ ] 擬似コードは実際のフレームワーク構文を使用しているか
+- [ ] クロスプラットフォームAPI契約は一貫しているか
+- [ ] エラー処理戦略は統一されているか
 
 ---
 
-### 4.4 フェーズ4：開発実装（System Developer）
+### 7.4 フェーズ4:開発実装(System Developer)
 
-**起動方法**：
+**開始方法**:
 ```
 @speccrew-system-developer 開発を開始
 ```
 
-**エージェントワークフロー**：
-1. システム設計文書を読み込む
-2. 各エンドの技術知識をロード
-3. **チェックポイントA**：環境プレチェック — ランタイムバージョン、依存関係、サービス可用性をチェック、失敗時はユーザー解決を待機
-4. タスクワーカーで各エンド開発を並列ディスパッチ
-5. 統合チェック：API契約の整合性、データ一貫性
-6. デリバリレポートを出力
+**エージェントワークフロー**:
+1. システム設計ドキュメントを読み込む
+2. 各プラットフォームの技術知識をロード
+3. **チェックポイントA**:環境プレチェック — ランタイムバージョン、依存関係、サービスの可用性をチェック、失敗した場合ユーザーの解決を待機
+4. Task Workerを使用して各プラットフォームの開発を並列配信
+5. 統合チェック:API契約の整合、データ一貫性
+6. 納品レポートを出力
 
-**成果物**：
+**成果物**:
 ```
 # ソースコードはプロジェクトの実際のソースディレクトリに書き込まれる
 iterations/{iter}/04.development/
@@ -250,55 +325,55 @@ iterations/{iter}/04.development/
 └── delivery-report.md
 ```
 
-**確認ポイント**：
-- [ ] 環境が準備完了か
-- [ ] 統合問題が許容範囲内か
-- [ ] コードが開発規約に準拠しているか
+**確認ポイント**:
+- [ ] 環境は準備完了か
+- [ ] 統合問題は許容範囲内か
+- [ ] コードは開発規約に準拠しているか
 
 ---
 
-### 4.5 フェーズ5：システムテスト（Test Manager）
+### 7.5 フェーズ5:システムテスト(Test Manager)
 
-**起動方法**：
+**開始方法**:
 ```
 @speccrew-test-manager テストを開始
 ```
 
-**3段階テストフロー**：
+**3段階テストプロセス**:
 
 | フェーズ | 説明 | チェックポイント |
 |------|------|------------|
-| テストケース設計 | PRDとFeature Specに基づいてテストケースを生成 | A：カバレッジ統計とトレースマトリックスを表示、ユーザー確認を待機 |
-| テストコード生成 | 実行可能なテストコードを生成 | B：生成されたテストファイルとケースマッピングを表示、ユーザー確認を待機 |
-| テスト実行とバグレポート | テストを自動実行、レポートを生成 | なし（自動実行） |
+| テストケース設計 | PRDとFeature Specに基づいてテストケースを生成 | A:ケースカバレッジ統計とトレースビリティマトリックスを表示、ユーザーがカバレッジ十分を確認するのを待機 |
+| テストコード生成 | 実行可能なテストコードを生成 | B:生成されたテストファイルとケースマッピングを表示、ユーザー確認を待機 |
+| テスト実行とバグレポート | テストを自動実行、レポートを生成 | なし(自動実行) |
 
-**成果物**：
+**成果物**:
 ```
 iterations/{iter}/05.system-test/
 ├── cases/
-│   └── {platform-id}/              # テストケース文書
+│   └── {platform-id}/              # テストケースドキュメント
 ├── code/
 │   └── {platform-id}/              # テストコード計画
 ├── reports/
 │   └── test-report-{date}.md       # テストレポート
 └── bugs/
-    └── BUG-{id}-{title}.md         # バグレポート（バグごとに1ファイル）
+    └── BUG-{id}-{title}.md         # バグレポート(バグごとに1ファイル)
 ```
 
-**確認ポイント**：
-- [ ] ケースカバレッジが完全か
-- [ ] テストコードが実行可能か
-- [ ] バグの重大度判定が正確か
+**確認ポイント**:
+- [ ] ケースカバレッジは完全か
+- [ ] テストコードは実行可能か
+- [ ] バグの深刻度判定は正確か
 
 ---
 
-### 4.6 フェーズ6：アーカイブ
+### 7.6 フェーズ6:アーカイブ
 
-イテレーション完了後に自動アーカイブ：
+イテレーション完了後自動的にアーカイブ:
 
 ```
 speccrew-workspace/iteration-archives/
-└── {シーケンス}-{タイプ}-{名前}-{日付}/
+└── {番号}-{タイプ}-{名前}-{日付}/
     ├── 01.product-requirement/
     ├── 02.feature-design/
     ├── 03.system-design/
@@ -308,13 +383,13 @@ speccrew-workspace/iteration-archives/
 
 ---
 
-## 5. ナレッジベースの説明
+## 8. ナレッジベース概要
 
-### 5.1 ビジネスナレッジベース（bizs）
+### 8.1 ビジネスナレッジベース(bizs)
 
-**目的**：プロジェクトのビジネス機能の説明、モジュール分割、API特性を保存
+**目的**:プロジェクトのビジネス機能説明、モジュール分割、API特性を保存
 
-**ディレクトリ構造**：
+**ディレクトリ構造**:
 ```
 knowledges/bizs/
 ├── {platform-type}/
@@ -323,13 +398,13 @@ knowledges/bizs/
 └── system-overview.md
 ```
 
-**使用シーン**：Product Manager、Feature Designer
+**使用シーン**:Product Manager、Feature Designer
 
-### 5.2 テクニカルナレッジベース（techs）
+### 8.2 テクニカルナレッジベース(techs)
 
-**目的**：プロジェクトのテクノロジースタック、アーキテクチャ規約、開発規約、テスト規約を保存
+**目的**:プロジェクトの技術スタック、アーキテクチャ規約、開発規約、テスト規約を保存
 
-**ディレクトリ構造**：
+**ディレクトリ構造**:
 ```
 knowledges/techs/{platform-id}/
 ├── tech-stack.md
@@ -339,54 +414,54 @@ knowledges/techs/{platform-id}/
 └── INDEX.md
 ```
 
-**使用シーン**：System Designer、System Developer、Test Manager
+**使用シーン**:System Designer、System Developer、Test Manager
 
 ---
 
-## 6. パイプライン進捗管理
+## 9. パイプライン進捗管理
 
-SpecCrew 仮想チームは厳密なフェーズゲートメカニズムに従い、各フェーズはユーザー確認後に次のフェーズに進む必要があります。また、ブレークポイントレジュームをサポート —— 中断後に再起動すると、自動的に前回停止した位置から継続します。
+SpecCrewバーチャルチームは厳格なステージゲーティングメカニズムに従い、各フェーズはユーザー確認後に次のフェーズに進むことができます。また、レジューム実行もサポート — 中断後再開時、前回の停止位置から自動的に続行します。
 
-### 6.1 三層進捗ファイル
+### 9.1 3層進捗ファイル
 
-ワークフローは自動的に3種類の JSON 進捗ファイルを維持し、イテレーションディレクトリに配置されます：
+ワークフローは自動的に3種類のJSON進捗ファイルを維持し、イテレーションディレクトリに配置:
 
-| ファイル | 位置 | 役割 |
+| ファイル | 位置 | 目的 |
 |------|------|------|
-| `WORKFLOW-PROGRESS.json` | `iterations/{iter}/` | パイプライン全体の各フェーズ状態を記録 |
-| `.checkpoints.json` | 各フェーズディレクトリ下 | ユーザーチェックポイント（Checkpoint）の通過状態を記録 |
-| `DISPATCH-PROGRESS.json` | 各フェーズディレクトリ下 | 並行タスク（複数プラットフォーム/モジュール）の個別進捗を記録 |
+| `WORKFLOW-PROGRESS.json` | `iterations/{iter}/` | パイプライン全体の各フェーズの状態を記録 |
+| `.checkpoints.json` | 各フェーズディレクトリ下 | ユーザー確認ポイント(Checkpoint)通過状態を記録 |
+| `DISPATCH-PROGRESS.json` | 各フェーズディレクトリ下 | 並列タスク(マルチプラットフォーム/マルチモジュール)の項目別進捗を記録 |
 
-### 6.2 フェーズ状態の遷移
+### 9.2 フェーズ状態フロー
 
-各フェーズは以下の状態遷移に従います：
+各フェーズは以下の状態フローに従います:
 
 ```
 pending → in_progress → completed → confirmed
 ```
 
-- **pending**：未開始
-- **in_progress**：実行中
-- **completed**：Agent 実行完了、ユーザー確認待ち
-- **confirmed**：ユーザーが最終 Checkpoint を確認、次のフェーズを開始可能
+- **pending**:まだ開始されていない
+- **in_progress**:実行中
+- **completed**:エージェント実行完了、ユーザー確認待ち
+- **confirmed**:ユーザーが最終Checkpointで確認、次のフェーズ開始可能
 
-### 6.3 ブレークポイントレジューム
+### 9.3 レジューム実行
 
-あるフェーズの Agent を再起動すると：
+フェーズのエージェントを再起動する場合:
 
-1. **上流の自動チェック**：前のフェーズが confirmed されているか検証、未確認の場合はブロックして警告
-2. **Checkpoint の復元**：`.checkpoints.json` を読み込み、通過済みの確認ポイントをスキップし、前回の中断位置から継続
-3. **並行タスクの復元**：`DISPATCH-PROGRESS.json` を読み込み、`pending` または `failed` 状態のタスクのみ再実行、既に `completed` のタスクはスキップ
+1. **上流自動チェック**:前のフェーズがconfirmedか検証、未確認の場合ブロックしてプロンプト
+2. **Checkpoint回復**:`.checkpoints.json`を読み込み、通過済みの確認ポイントをスキップ、前回の中断場所から続行
+3. **並列タスク回復**:`DISPATCH-PROGRESS.json`を読み込み、`pending`または`failed`状態のタスクのみ再実行、`completed`タスクをスキップ
 
-### 6.4 現在の進捗を確認
+### 9.4 現在の進捗 viewing
 
-Team Leader Agent を通じてパイプラインの全体状態を確認：
+Team Leaderエージェントを通じてパイプラインパノラマ状態を表示:
 
 ```
-@speccrew-team-leader 現在のイテレーション進捗を確認
+@speccrew-team-leader 現在のイテレーション進捗を表示
 ```
 
-Team Leader は進捗ファイルを読み込み、以下のような状態概要を表示します：
+Team Leaderは進捗ファイルを読み込み、以下のような状態概要を表示:
 
 ```
 Pipeline Status: i001-user-management
@@ -397,29 +472,29 @@ Pipeline Status: i001-user-management
   05 System Test:    ⏳ Pending
 ```
 
-### 6.5 下位互換性
+### 9.5 下位互換性
 
-進捗ファイルメカニズムは完全に下位互換 —— 進捗ファイルが存在しない場合（古いプロジェクトや新規イテレーションなど）、すべての Agent は元のロジックで正常に実行されます。
+進捗ファイルメカニズムは完全に下位互換性があります — 進捗ファイルが存在しない場合(旧プロジェクトや新しいイテレーションなど)、すべてのエージェントは元のロジックに従って正常に実行します。
 
 ---
 
-## 7. よくある質問（FAQ）
+## 10. よくある質問(FAQ)
 
-### Q1: エージェントが期待通りに動作しない場合は？
+### Q1: エージェントが期待通りに動作しない場合は?
 
-1. `speccrew doctor`を実行してインストールの完全性をチェック
+1. `speccrew doctor` を実行してインストールの完全性をチェック
 2. ナレッジベースが初期化されていることを確認
-3. 現在のイテレーションディレクトリに前フェーズの成果物があることを確認
+3. 現在のイテレーションディレクトリに前のフェーズの成果物が存在することを確認
 
-### Q2: フェーズをスキップするには？
+### Q2: フェーズをスキップするには?
 
-**スキップは推奨されません**。各フェーズの成果物は次のフェーズの入力です。
+**スキップ非推奨** — 各フェーズの出力は次のフェーズの入力です。
 
-スキップが必須の場合は、対応するフェーズの入力文書を手動で準備し、形式が仕様に準拠していることを確認してください。
+スキップが必要な場合は、対応するフェーズの入力ドキュメントを手動で準備し、フォーマット仕様に従っていることを確認してください。
 
-### Q3: 複数の要件を並列処理するには？
+### Q3: 複数の並列要件を処理するには?
 
-各要件に独立したイテレーションディレクトリを作成：
+各要件に対して独立したイテレーションディレクトリを作成:
 ```
 iterations/
 ├── 001-feature-xxx/
@@ -427,96 +502,96 @@ iterations/
 └── 003-feature-zzz/
 ```
 
-各イテレーションは完全に隔離され、相互に影響しません。
+各イテレーションは完全に分離され、相互に影響しません。
 
-### Q4: SpecCrewのバージョンを更新するには？
+### Q4: SpecCrewバージョンを更新するには?
 
-更新は2つのステップで行います：
+更新は2つのステップが必要です:
 
 ```bash
-# ステップ1：グローバルCLIツールを更新
+# ステップ1: グローバルCLIツールを更新
 npm install -g speccrew@latest
 
-# ステップ2：プロジェクトディレクトリでAgentsとSkillsを同期
+# ステップ2: プロジェクトディレクトリでエージェントとスキルを同期
 cd /path/to/your-project
 speccrew update
 ```
 
-- `npm install -g speccrew@latest`：CLIツール自体を更新（新バージョンには新しいAgent/Skill定義、バグ修正などが含まれる場合があります）
-- `speccrew update`：プロジェクトのAgentおよびSkill定義ファイルを最新バージョンに同期
-- `speccrew update --ide cursor`：指定したIDEの設定のみを更新
+- `npm install -g speccrew@latest`:CLIツール自体を更新(新バージョンには新しいエージェント/スキル定義、バグ修正などが含まれる場合があります)
+- `speccrew update`:プロジェクト内のエージェントとスキル定義ファイルを最新バージョンに同期
+- `speccrew update --ide cursor`:指定されたIDEの構成のみを更新
 
-> **注意**：両方のステップを実行する必要があります。`speccrew update`のみを実行してもCLIツール自体は更新されません；`npm install`のみを実行してもプロジェクト内のファイルは更新されません。
+> **注意**:両方のステップが必要です。`speccrew update` のみを実行してもCLIツール自体は更新されません;`npm install` のみを実行してもプロジェクトファイルは更新されません。
 
-### Q5: `speccrew update` で新バージョンが利用可能と表示されるが、`npm install -g speccrew@latest` でも古いバージョンがインストールされる？
+### Q5: `speccrew update` は新バージョンが利用可能と表示されるが、`npm install -g speccrew@latest` は古いバージョンをインストールする?
 
-これは通常npmキャッシュが原因です。解決方法：
+これは通常npmキャッシュが原因です。解決方法:
 
 ```bash
 # npmキャッシュをクリアして再インストール
 npm cache clean --force
 npm install -g speccrew@latest
 
-# バージョンを確認
+# バージョンを検証
 npm list -g speccrew
 ```
 
-それでも解決しない場合は、特定のバージョン番号を指定してインストールしてみてください：
+それでもうまくいかない場合は、特定のバージョン番号を指定してインストールしてみてください:
 ```bash
 npm install -g speccrew@0.5.6
 ```
 
-### Q6: 過去のイテレーションを表示するには？
+### Q6: 履歴イテレーションを表示するには?
 
-アーカイブ後、`speccrew-workspace/iteration-archives/`で表示、`{シーケンス}-{タイプ}-{名前}-{日付}/`形式で整理。
+アーカイブ後、`speccrew-workspace/iteration-archives/` で表示、`{番号}-{タイプ}-{名前}-{日付}/` 形式で整理。
 
-### Q7: ナレッジベースは定期的に更新が必要ですか？
+### Q7: ナレッジベースは定期的に更新する必要がありますか?
 
-以下の場合は再初期化が必要です：
-- プロジェクト構造が大幅に変更
-- テクノロジースタックのアップグレードまたは変更
+以下の状況で再初期化が必要です:
+- プロジェクト構造の重大な変更
+- 技術スタックのアップグレードまたは交換
 - ビジネスモジュールの追加/削除
 
 ---
 
-## 8. クイックリファレンス
+## 11. クイックリファレンス
 
-### エージェント起動クイックリファレンス表
+### エージェント起動クイックリファレンス
 
-| フェーズ | エージェント | 起動会話 |
-|------|-------|----------|
+| フェーズ | エージェント | 開始会話 |
+|-------|-------|-------------------|
 | 初期化 | Team Leader | `@speccrew-team-leader テクニカルナレッジベースを初期化` |
-| 要件分析 | Product Manager | `@speccrew-product-manager 新しい要件があります：[説明]` |
+| 要件分析 | Product Manager | `@speccrew-product-manager 新しい要件があります:[説明]` |
 | 機能設計 | Feature Designer | `@speccrew-feature-designer 機能設計を開始` |
 | システム設計 | System Designer | `@speccrew-system-designer システム設計を開始` |
-| 開発実装 | System Developer | `@speccrew-system-developer 開発を開始` |
+| 開発 | System Developer | `@speccrew-system-developer 開発を開始` |
 | システムテスト | Test Manager | `@speccrew-test-manager テストを開始` |
 
 ### チェックポイントチェックリスト
 
 | フェーズ | チェックポイント数 | 主要チェック項目 |
-|------|-----------------|------------|
+|-------|----------------------|-----------------|
 | 要件分析 | 1 | 要件の正確性、ビジネスルールの完全性、受け入れ基準の測定可能性 |
 | 機能設計 | 1 | シナリオカバレッジ、インタラクションの明確さ、データの完全性、例外処理 |
-| システム設計 | 2 | A: フレームワーク評価；B: 擬似コード構文、クロスエンドの一貫性、エラー処理 |
-| 開発実装 | 1 | A: 環境準備完了、統合問題、コード規約 |
-| システムテスト | 2 | A: ケースカバレッジ；B: テストコードの実行可能性 |
+| システム設計 | 2 | A: フレームワーク評価; B: 擬似コード構文、クロスプラットフォーム一貫性、エラー処理 |
+| 開発 | 1 | A: 環境の準備、統合問題、コード規約 |
+| システムテスト | 2 | A: ケースカバレッジ; B: テストコードの実行可能性 |
 
 ### 成果物パスクイックリファレンス
 
 | フェーズ | 出力ディレクトリ | ファイル形式 |
-|------|----------|----------|
+|-------|-----------------|-------------|
 | 要件分析 | `iterations/{iter}/01.product-requirement/` | `[name]-prd.md`, `[name]-bizs-modeling.md` |
 | 機能設計 | `iterations/{iter}/02.feature-design/` | `[name]-feature-spec.md` |
 | システム設計 | `iterations/{iter}/03.system-design/` | `DESIGN-OVERVIEW.md`, `{platform}/INDEX.md`, `{platform}/{module}-design.md` |
-| 開発実装 | `iterations/{iter}/04.development/` | ソースコード + `delivery-report.md` |
+| 開発 | `iterations/{iter}/04.development/` | ソースコード + `delivery-report.md` |
 | システムテスト | `iterations/{iter}/05.system-test/` | `cases/`, `code/`, `reports/`, `bugs/` |
 | アーカイブ | `iteration-archives/{iter}-{date}/` | 完全なイテレーションコピー |
 
 ---
 
-## 9. 次のステップ
+## 次のステップ
 
-1. `speccrew init --ide qoder`を実行してプロジェクトを初期化
-2. ステップ0を実行：ナレッジベース初期化
-3. ワークフローに従ってフェーズごとに進め、仕様駆動の開発体験を楽しんでください！
+1. `speccrew init --ide qoder` を実行してプロジェクトを初期化
+2. ステップ0を実行: ナレッジベース初期化
+3. ワークフローに従って各フェーズを進め、仕様駆動の開発体験をお楽しみください!