musubix2 0.3.7 → 0.4.0

package/.claude/skills/requirements-analyst/SKILL.md

@@ -0,0 +1,158 @@
+---
+name: requirements-analyst
+description: >
+  EARS形式で要件を分析・作成・検証する。MarkdownEARSParser による構文検証、
+  EARSValidator による信頼度スコア算出、対話的要件ウィザードを提供。
+  Use when creating requirements, validating EARS compliance, analyzing
+  requirement documents, or starting SDD Phase 1.
+license: MIT
+version: "1.0.0"
+triggers:
+  - 要件を作成
+  - 要件を分析
+  - EARS 検証
+  - Phase 1 開始
+  - requirements
+---
+
+# Requirements Analyst
+
+EARS（Easy Approach to Requirements Syntax）形式で要件を分析・作成・検証するスキル。
+SDD ワークフロー Phase 1 の中核。
+
+## 前提条件
+
+- `steering/` を参照済みであること（Article VI: プロジェクトメモリ）
+- 対象プロジェクトに `storage/specs/` ディレクトリが存在すること
+
+## EARS パターン分類
+
+| パターン | 構文 | 信頼度ボーナス |
+|----------|------|---------------|
+| UBIQUITOUS | THE システム SHALL... | +0.00 |
+| EVENT-DRIVEN | WHEN \<event\>, THE システム SHALL... | +0.25 |
+| STATE-DRIVEN | WHILE \<state\>, THE システム SHALL... | +0.25 |
+| UNWANTED | THE システム SHALL NOT... | +0.20 |
+| OPTIONAL | WHERE \<feature\>, THE システム SHALL... | +0.20 |
+| COMPLEX | IF \<condition\>, THEN THE システム SHALL... | +0.15 |
+
+信頼度 0.85 以上で早期終了最適化。
+
+## ワークフロー
+
+### 1. 要件分析（既存文書の検証）
+
+```
+WHEN ユーザーが要件文書の検証を要求する:
+1. MarkdownEARSParser で要件を抽出（ParsedRequirement[]）
+2. EARSValidator で各要件を分類・信頼度算出
+3. 違反箇所の位置特定 + 修正提案を生成
+4. RequirementsValidator で構文準拠チェック
+5. TraceabilityValidator でカバレッジレポート生成
+```
+
+**CLI**: `npx musubix req <file>`
+
+### 2. 対話的要件作成
+
+```
+WHEN ユーザーが新規要件の作成を要求する:
+1. feature 名をヒアリング
+2. EARS パターンを選択（6種類から）
+3. トリガー/条件を入力
+4. EARS 文を自動生成
+5. AcceptanceCriteriaGenerator で受入基準を生成（LLM利用）
+6. ユーザー承認 ⏸️
+```
+
+**CLI**: `npx musubix req:wizard`
+
+### 3. 要件検索
+
+```
+WHEN ユーザーが要件の検索を要求する:
+1. RequirementsValidator.search() で全文検索
+```
+
+## 要件文書フォーマット
+
+各要件は以下の7フィールドを含む:
+
+```markdown
+### REQ-XXX-NNN: タイトル
+
+**種別**: UBIQUITOUS | EVENT-DRIVEN | STATE-DRIVEN | UNWANTED | OPTIONAL | COMPLEX
+**優先度**: P0 | P1 | P2
+
+**要件**:
+THE システム SHALL...
+
+**受入基準**:
+- [ ] 基準1
+- [ ] 基準2
+
+**トレーサビリティ**: DES-XXX-NNN
+**パッケージ**: `package-name`
+**CLI**: `npx musubix ...`
+```
+
+## 品質ゲート
+
+- [ ] 全要件が EARS 6パターンのいずれかに分類可能
+- [ ] 信頼度スコア 0.70 以上（低い場合は修正提案）
+- [ ] 受入基準がチェックリスト形式
+- [ ] トレーサビリティフィールドが存在
+- [ ] パッケージフィールドが存在
+
+## 4. 要件インタビュー（1問1答フロー）
+
+```
+WHEN ユーザーが要件仕様書の生成を要求する:
+1. RequirementsInterviewer にユーザーの入力テキストを渡す
+2. extractFromInput() でキーワードマッチングにより既知情報を抽出
+3. 不足している必須項目を1問ずつ質問（1問1答）
+4. 必須項目: プロジェクト名、概要、システム種別、対象ユーザー、主要機能
+5. 任意項目: ステークホルダー、ユースケース、パフォーマンス、セキュリティ等
+6. 全必須項目が揃ったら RequirementsDocGenerator で EARS 準拠仕様書を生成
+7. EARSValidator で生成結果を検証
+```
+
+### インタビューフロー詳細
+
+1. **入力分析**: ユーザーの自由記述からプロジェクト名・機能・技術スタック等を自動抽出
+2. **不足情報特定**: 必須フィールド（projectName, projectDescription, projectDomain, targetUsers, features）の充足チェック
+3. **1問1答**: 不足フィールドごとに1問ずつ質問（日本語メイン、英語サブ）
+4. **回答適用**: 回答をコンテキストに格納し、完了率を更新
+5. **仕様書生成**: 全必須項目充足後、EARS形式の要件仕様書を自動生成
+
+**CLI**:
+```
+npx musubix req:interview <input-text>             # 入力分析 → 最初の質問
+npx musubix req:interview --answer <id> <response>  # 質問に回答
+npx musubix req:interview --state                    # 現在の状態表示
+npx musubix req:interview --generate                 # 仕様書生成
+npx musubix req:interview --reset                    # リセット
+```
+
+**MCP Tools**:
+- `sdd.requirements.interview.start` — インタビュー開始
+- `sdd.requirements.interview.answer` — 質問に回答
+- `sdd.requirements.interview.state` — 状態取得
+- `sdd.requirements.interview.generate` — 仕様書生成
+
+## Gotchas
+
+1. **EARS パターン混在に注意**: 1つの要件に複数パターンが混在する場合、COMPLEX に分類する。「WHEN ... WHILE ...」は COMPLEX。
+2. **受入基準の粒度**: 「動作すること」のような曖昧な基準は不合格。具体的なコマンド・出力・閾値を含めること。
+3. **トレーサビリティの双方向性**: REQ → DES だけでなく、DES → REQ の逆参照も維持する。片方向のみは Article V 違反。
+
+## スクリプト
+
+| スクリプト | 説明 | 使い方 |
+|-----------|------|--------|
+| `scripts/analyze.sh` | 要件分析 | `./scripts/analyze.sh <requirements-file.md>` |
+| `scripts/validate.sh` | EARS 準拠検証 | `./scripts/validate.sh <requirements-file.md>` |
+| `scripts/interview.sh` | 1問1答インタビュー開始 | `./scripts/interview.sh [input-text]` |
+| `scripts/interview-answer.sh` | インタビュー質問に回答 | `./scripts/interview-answer.sh <id> <response>` |
+| `scripts/interview-generate.sh` | インタビューから要件生成 | `./scripts/interview-generate.sh` |
+| `scripts/wizard.sh` | 要件ウィザード実行 | `./scripts/wizard.sh` |

package/.claude/skills/requirements-analyst/scripts/analyze.sh

@@ -0,0 +1,5 @@
+#!/bin/bash
+# Analyze requirements from a markdown file
+set -e
+FILE="${1:?Usage: analyze.sh <requirements-file.md>}"
+npx musubix req "$FILE"

package/.claude/skills/requirements-analyst/scripts/interview-answer.sh

@@ -0,0 +1,4 @@
+#!/bin/bash
+# Answer an interview question
+set -e
+npx musubix req:interview --answer "$1" "$2"

package/.claude/skills/requirements-analyst/scripts/interview-generate.sh

@@ -0,0 +1,4 @@
+#!/bin/bash
+# Generate requirements from interview
+set -e
+npx musubix req:interview --generate

package/.claude/skills/requirements-analyst/scripts/interview.sh

@@ -0,0 +1,9 @@
+#!/bin/bash
+# Start 1問1答 requirements interview
+set -e
+INPUT="${1:-}"
+if [ -n "$INPUT" ]; then
+  npx musubix req:interview "$INPUT"
+else
+  npx musubix req:interview
+fi

package/.claude/skills/requirements-analyst/scripts/validate.sh

@@ -0,0 +1,5 @@
+#!/bin/bash
+# Validate requirements EARS compliance
+set -e
+FILE="${1:?Usage: validate.sh <requirements-file.md>}"
+npx musubix req "$FILE"

package/.claude/skills/requirements-analyst/scripts/wizard.sh

@@ -0,0 +1,4 @@
+#!/bin/bash
+# Run requirements wizard
+set -e
+npx musubix req:wizard

package/.claude/skills/review-orchestrator/SKILL.md

@@ -0,0 +1,162 @@
+---
+name: review-orchestrator
+description: >
+  複数AIモデル(opus-4.6/gpt-5.4)による交互レビューでSDD成果物の品質を保証。
+  Qiita記事(AI Scrum Team)に着想を得た交互レビューパターンで、
+  requirements / design / plan アーティファクトの合意チェックと実装許可判定を行う。
+license: MIT
+version: "1.0.0"
+triggers:
+  - レビューオーケストレーション
+  - 交互レビュー
+  - cross-model review
+  - 合意チェック
+  - consensus
+  - 実装許可
+  - review pipeline
+  - アーティファクトレビュー
+---
+
+# Review Orchestrator
+
+Qiita 記事（AI Scrum Team）に着想を得た、複数 AI モデルによる交互レビューパターンで
+SDD 成果物の品質を保証するスキル。
+opus-4.6 と gpt-5.4 が交互にレビューし、両モデルの合意を以て実装フェーズへの遷移を許可する。
+
+## 前提条件
+
+- `steering/` を参照済みであること（Article VI: プロジェクトメモリ）
+- レビュー対象アーティファクトが `references/musubix2/` に存在すること
+- `@musubix2/agent-orchestrator` パッケージの `ReviewOrchestrator` クラスが利用可能であること
+
+## 目的
+
+複数 AI モデルの視点を組み合わせることで、単一モデルでは見落としやすい問題を検出する。
+各モデルの得意分野（論理的厳密性 vs 実用性・網羅性）を相補的に活用し、
+SDD アーティファクトの品質を最大化する。
+
+## レビュープロセス
+
+### Phase 1: 交互レビュー
+
+```
+WHEN アーティファクトのレビューが要求される:
+1. Model A (Claude Opus 4.6) がアーティファクトをレビュー
+2. 発見された問題を Model B (GPT-5.4) に渡してレビュー
+3. Model B の指摘を Model A に渡して再レビュー
+4. エラーが 0 になるまで交互に繰り返す（最大 5 ラウンド）
+5. 各ラウンドの ReviewResult を記録
+```
+
+### Phase 2: 最終合意チェック
+
+```
+WHEN 交互レビューでエラーが 0 になった場合:
+1. 両モデルが同時（並列）にアーティファクトをレビュー
+2. 両方が PASS した場合のみ、そのアーティファクトを「承認済み」とする
+3. どちらかが FAIL の場合、Phase 1 に戻る
+```
+
+### Phase 3: 実装許可判定
+
+```
+WHEN 全アーティファクトの合意チェックが完了した場合:
+1. requirements (REQ-*) が承認済みか確認
+2. design (DES-*) が承認済みか確認
+3. plan (PLAN-*) が承認済みか確認
+4. 全て承認済みの場合 canProceedToImplementation() = true
+5. 未承認がある場合、不足アーティファクトを報告
+```
+
+## 対象アーティファクト
+
+| 種別 | ID 形式 | ファイル例 |
+|------|---------|-----------|
+| Requirements | REQ-* | `references/musubix2/REQ-MUSUBIX2-001.md` |
+| Design | DES-* | `references/musubix2/DES-MUSUBIX2-001.md` |
+| Plan | PLAN-* | `references/musubix2/PLAN-MUSUBIX2-001.md` |
+
+## レビュー基準
+
+### Requirements（要件定義書）
+
+- [ ] 全要件が EARS 形式（6パターン）に準拠
+- [ ] 各要件に受入基準がチェックリスト形式で存在
+- [ ] 一意な ID（REQ-XXX-NNN）が付与されている
+- [ ] トレーサビリティフィールド（DES 参照）が存在
+- [ ] パッケージフィールドが存在
+
+### Design（設計書）
+
+- [ ] SOLID 原則に準拠した設計
+- [ ] DES-ID が対応する REQ-ID にトレース可能
+- [ ] 型定義が実装と整合している
+- [ ] Mermaid 図（クラス図・シーケンス図）が含まれる
+- [ ] 4層アーキテクチャ（Domain/Application/Infrastructure/Interface）に準拠
+
+### Plan（実装計画）
+
+- [ ] タスク間の依存関係が明示されている
+- [ ] DES カバレッジが 100%（全 DES に対応タスクが存在）
+- [ ] フェーズ順序が SDD ワークフローに準拠
+- [ ] 各タスクに見積もりと担当パッケージが記載
+
+## コマンド例
+
+```
+@review-orchestrator requirements をレビュー
+@review-orchestrator design をレビュー
+@review-orchestrator plan をレビュー
+@review-orchestrator 全パイプラインレビュー
+@review-orchestrator 合意チェックを実行
+@review-orchestrator 実装に進めるか確認
+```
+
+## 使用するパッケージ
+
+`@musubix2/agent-orchestrator` パッケージの `ReviewOrchestrator` クラスを使用する。
+
+```typescript
+import { ReviewOrchestrator } from '@musubix2/agent-orchestrator';
+
+const orchestrator = new ReviewOrchestrator();
+
+// 単一アーティファクトのレビュー
+const result = await orchestrator.reviewArtifact('requirements', content);
+
+// パイプラインレビュー（全アーティファクト）
+const pipeline = await orchestrator.runPipelineReview({
+  requirements: reqContent,
+  design: desContent,
+  plan: planContent,
+});
+
+// 実装許可判定
+const canProceed = orchestrator.canProceedToImplementation();
+```
+
+## 品質ゲート
+
+- [ ] 交互レビューでエラー 0 を達成
+- [ ] 両モデルの最終合意チェックが PASS
+- [ ] 全アーティファクト（requirements, design, plan）が承認済み
+- [ ] レビュー結果が構造化された ReviewResult として記録済み
+
+## 制約
+
+1. **自動修正は行わない**: 問題点の指摘と修正提案のみを行う。実際の修正はユーザーまたは担当スキルが実施する。
+2. **最大5ラウンド制限**: 交互レビューが 5 ラウンドで合意に至らない場合は人間の介入を要求する。無限ループを防止。
+3. **品質ゲート bypass 禁止**: レビュー結果を無視して実装フェーズに遷移してはならない。
+4. **レビュー結果の永続化**: 全レビュー結果を ReviewResult 形式で記録し、トレーサビリティを維持する。
+
+## Gotchas
+
+1. **モデル応答のばらつき**: 同じアーティファクトでもモデルの応答が異なる場合がある。合意チェックで一貫性を担保する。
+2. **ラウンド数と品質のトレードオフ**: ラウンド数が多いほど品質は上がるが、時間コストも増加する。5 ラウンド制限はこのバランスを取るもの。
+3. **Phase 遷移との連携**: review-orchestrator の承認は PhaseController の遷移条件に組み込まれる。review-orchestrator 単体では Phase を遷移させない。
+
+## スクリプト
+
+| スクリプト | 説明 | 使い方 |
+|-----------|------|--------|
+| `scripts/review.sh` | レビューワークフロー案内 | `./scripts/review.sh` |

package/.claude/skills/review-orchestrator/review-orchestrator.prompt.md

@@ -0,0 +1,45 @@
+---
+description: "SDD Review Orchestrator — 交互レビューによるアーティファクト品質保証"
+mode: agent
+tools: ["editFiles", "codebase", "terminal"]
+---
+
+# SDD Review Orchestrator
+
+あなたは **SDD Review Orchestrator** です。
+要件定義書、設計書、実装計画の品質を、複数のAIモデルによる交互レビューで保証します。
+
+詳細なプレイブックは `skills/review-orchestrator/SKILL.md` を参照してください。
+実装は `@musubix2/agent-orchestrator` パッケージの `ReviewOrchestrator` クラスを使用します。
+
+## レビュープロセス
+
+### Phase 1: 交互レビュー
+1. **Model A (Claude Opus 4.6)** がアーティファクトをレビュー
+2. 発見された問題を **Model B (GPT-5.4)** に渡してレビュー
+3. エラーがなくなるまで交互に繰り返す（最大5ラウンド）
+
+### Phase 2: 最終合意チェック
+4. 両モデルが同時にレビューを実施
+5. **両方がPASS**した場合のみ、実装フェーズに進行可能
+
+### Phase 3: 実装許可
+6. 全アーティファクト（requirements, design, plan）が承認済みの場合のみ
+7. `canProceedToImplementation()` が `true` を返す
+
+## レビュー基準
+- **要件定義**: EARS形式準拠、受入基準、一意ID、トレーサビリティ
+- **設計書**: SOLID原則、DES-ID対応、型定義の整合性
+- **実装計画**: タスク依存関係、DESカバレッジ100%、フェーズ順序
+
+## 使い方
+```
+@review-orchestrator requirements を レビューしてください
+@review-orchestrator 全アーティファクトのパイプラインレビューを実行
+@review-orchestrator 実装に進めるか確認
+```
+
+## 制約
+- レビュー結果は必ず構造化された ReviewResult として記録
+- 自動修正は行わない（問題点と修正提案のみ）
+- 最大5ラウンドで合意に至らない場合は人間の介入を要求

package/.claude/skills/review-orchestrator/scripts/review.sh

@@ -0,0 +1,13 @@
+#!/bin/bash
+# Start review workflow
+set -e
+echo "Review Orchestrator"
+echo "==================="
+echo "This skill orchestrates cross-model reviews."
+echo ""
+echo "Available commands:"
+echo "  npx musubix workflow      # Workflow management"
+echo "  npx musubix policy        # Policy validation"
+echo "  npx musubix trace:verify  # Traceability check"
+echo ""
+echo "For full review orchestration, use the AI agent with this skill."

package/.claude/skills/test-engineer/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: test-engineer
+description: >
+  テストファースト（Red→Green→Blue）サイクルを強制し、ユニットテスト生成、
+  カバレッジ検証、EARS ID リンケージを実行する。Vitest ベース。
+  Use when creating tests, checking coverage, enforcing test-first policy,
+  running quality gates, or validating Article III compliance.
+license: MIT
+version: "1.0.0"
+triggers:
+  - テスト作成
+  - テスト実行
+  - カバレッジ
+  - Red-Green-Blue
+  - test-first
+  - Article III
+---
+
+# Test Engineer
+
+テストファースト（Red→Green→Blue）開発サイクルを強制するスキル。
+Article III（テストファースト）と Article IX（品質ゲート）の執行者。
+
+## 前提条件
+
+- `steering/` を参照済みであること
+- Vitest が設定済みであること（`vitest.config.ts`）
+- テスト対象の DES 仕様が存在すること
+
+## Red→Green→Blue サイクル
+
+```
+1. RED:   失敗するテストを書く（EARS 要件 ID をテスト名に含む）
+2. GREEN: テストが通る最小限のコードを書く
+3. BLUE:  リファクタリング（テストは緑のまま）
+```
+
+**このサイクルの順序をスキップしてはならない。**
+
+## ワークフロー
+
+### 1. テスト生成
+
+```
+WHEN ユーザーがテスト生成を要求する:
+1. DES 仕様の受入基準を解析
+2. UnitTestGenerator で Vitest テストケースを生成
+3. 各テストに EARS 要件 ID をリンク: describe('REQ-XXX-NNN: ...')
+4. CoverageReporter でカバレッジ目標を設定
+```
+
+**CLI**: `npx musubix test:gen <source-file>`
+
+### 2. カバレッジ検証
+
+```
+WHEN ユーザーがカバレッジ確認を要求する:
+1. Vitest カバレッジレポートを取得
+2. CoverageGateConfig の閾値（80%）と比較
+3. 未カバーの EARS 要件を検出
+4. 不足テストの提案を生成
+```
+
+**CLI**: `npx vitest run --coverage`
+
+### 3. 品質ゲートチェック
+
+```
+WHEN Phase 遷移時に品質ゲートを実行する:
+1. QualityGateRunner で全ゲートを実行
+2. テストカバレッジ ≥ 80%
+3. 全 EARS 要件に対応するテストが存在
+4. 全テストが PASS
+5. 結果をレポート
+```
+
+## テストファイル配置
+
+```
+packages/<name>/tests/
+├── domain/
+│   └── <Entity>.test.ts
+├── application/
+│   └── <Service>.test.ts
+└── integration/
+    └── <Feature>.integration.test.ts
+```
+
+## テスト命名規約
+
+```typescript
+describe('REQ-XXX-NNN: 要件タイトル', () => {
+  it('should <期待動作> when <条件>', () => {
+    // Arrange
+    // Act
+    // Assert
+  });
+});
+```
+
+## Vitest 設定基準
+
+```typescript
+// vitest.config.ts
+export default defineConfig({
+  test: {
+    coverage: {
+      provider: 'v8',
+      reporter: ['text', 'json', 'html'],
+      thresholds: {
+        lines: 80,
+        functions: 80,
+        branches: 80,
+        statements: 80,
+      },
+    },
+  },
+});
+```
+
+## 品質ゲート
+
+- [ ] テストカバレッジ 80% 以上（lines, functions, branches, statements）
+- [ ] 全 EARS 要件に少なくとも1つのテストが対応
+- [ ] テスト名に REQ ID がリンクされている
+- [ ] Red→Green→Blue の順序が守られている
+- [ ] 全テストが PASS
+
+## Gotchas
+
+1. **テストなしのコミット禁止**: Article III により、テストのないコードは Phase 4 完了の品質ゲートを通過できない。
+2. **モック依存の分離**: `SkillTestHarness` パターンに従い、外部依存はモック注入する。テスト内で直接ファイルシステムにアクセスしない。
+3. **EARS ID リンクの維持**: テスト名を変更する場合、REQ ID リンクも必ず更新する。`traceability-auditor` で検証可能。
+
+## スクリプト
+
+| スクリプト | 説明 | 使い方 |
+|-----------|------|--------|
+| `scripts/generate.sh` | テスト生成 | `./scripts/generate.sh [args]` |

package/.claude/skills/test-engineer/scripts/generate.sh

@@ -0,0 +1,4 @@
+#!/bin/bash
+# Generate tests
+set -e
+npx musubix test:gen "$@"

package/.claude/skills/traceability-auditor/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: traceability-auditor
+description: >
+  要件↔設計↔コード↔テスト間の 100% トレーサビリティを監査する。
+  トレーサビリティマトリクス生成、ギャップ検出、影響分析、同期検証を提供。
+  Use when checking traceability coverage, generating trace matrices,
+  analyzing change impact, or validating Article V compliance.
+license: MIT
+version: "1.0.0"
+triggers:
+  - トレーサビリティ
+  - マトリクス生成
+  - 影響分析
+  - カバレッジ確認
+  - Article V
+  - trace
+---
+
+# Traceability Auditor
+
+要件 ↔ 設計 ↔ コード ↔ テスト間の 100% トレーサビリティを監査するスキル。
+Article V（トレーサビリティ）の執行者。
+
+## 前提条件
+
+- `steering/` を参照済みであること
+- 要件文書（`REQ-*.md`）と設計文書（`DES-*.md`）が存在すること
+
+## トレースリンク構造
+
+```
+REQ-XXX-NNN ←→ DES-XXX-NNN ←→ src/<package>/... ←→ tests/<package>/...
+     ↑                                                        ↑
+     └────────────────── EARS ID リンケージ ──────────────────┘
+```
+
+## ワークフロー
+
+### 1. トレーサビリティマトリクス生成
+
+```
+WHEN ユーザーがトレーサビリティマトリクスの生成を要求する:
+1. TraceabilityManager で全 TraceLink を収集
+2. MatrixGenerator でマトリクスを生成
+3. GapInfo で未カバー項目を検出
+4. Markdown 形式で出力
+```
+
+**CLI**: `npx musubix trace matrix [--format md|json|csv]`
+
+### 2. トレーサビリティ検証
+
+```
+WHEN ユーザーがトレーサビリティの検証を要求する:
+1. 全 REQ ID を抽出
+2. 各 REQ に対応する DES を検索
+3. 各 DES に対応するソースファイルを検索
+4. 各ソースに対応するテストを検索
+5. 欠落リンクをレポート
+```
+
+**CLI**: `npx musubix trace validate`
+**CLI**: `npx musubix trace:verify`
+
+### 3. 影響分析
+
+```
+WHEN ユーザーが変更影響分析を要求する:
+1. ImpactAnalyzer で変更された REQ/DES を特定
+2. 影響を受けるコード・テストを列挙
+3. 必要な更新箇所をレポート
+```
+
+**CLI**: `npx musubix trace impact <req-id|des-id>`
+
+### 4. 影響分析レポート
+
+```
+WHEN ユーザーが影響分析レポートの生成を要求する:
+1. ImpactAnalyzer で変更影響をまとめる
+2. 影響範囲を Markdown 形式でレポート
+```
+
+## マトリクス出力フォーマット
+
+```markdown
+| REQ ID | DES ID | Package | Source | Test | Status |
+|--------|--------|---------|--------|------|--------|
+| REQ-ARC-001 | DES-ARC-001 | core | ✅ | ✅ | COVERED |
+| REQ-ARC-002 | DES-ARC-002 | core | ✅ | ❌ | PARTIAL |
+| REQ-SKL-001 | DES-SKL-001 | skill-manager | ❌ | ❌ | MISSING |
+```
+
+## 品質ゲート
+
+- [ ] 全 REQ に対応する DES が存在する（REQ → DES 100%）
+- [ ] 全 DES に対応するソースコードが存在する（DES → Code）
+- [ ] 全 REQ に対応するテストが存在する（REQ → Test）
+- [ ] 双方向リンクが維持されている（REQ ← → DES）
+- [ ] ギャップ数が 0
+
+## Gotchas
+
+1. **N:M 関係の扱い**: 1つの REQ が複数の DES にマッピングされる場合がある。マトリクスでは全組み合わせを列挙すること。
+2. **DES-SDD-002a/b/c のような複合 ID**: サフィックス付き ID も個別にトレースすること。グループ化表記（`002a/b/c`）は表示用。
+3. **コード内の REQ ID コメント**: `// REQ-XXX-NNN` 形式のコメントを検索対象にする。テスト内の `describe('REQ-XXX-NNN: ...')` も対象。
+
+## スクリプト
+
+| スクリプト | 説明 | 使い方 |
+|-----------|------|--------|
+| `scripts/verify.sh` | トレーサビリティ検証 | `./scripts/verify.sh [args]` |
+| `scripts/matrix.sh` | トレーサビリティマトリクス生成 | `./scripts/matrix.sh [args]` |
+| `scripts/verify-detailed.sh` | 詳細トレーサビリティ検証 | `./scripts/verify-detailed.sh [args]` |

package/.claude/skills/traceability-auditor/scripts/matrix.sh

@@ -0,0 +1,4 @@
+#!/bin/bash
+# Generate traceability matrix
+set -e
+npx musubix trace "$@"