---
name: merge-specs
description: >
  分割された仕様書（spec）を重複・矛盾なく1ファイルに統合する。
  Use when: "specを統合", "要件定義書をまとめて", "merge specs", "/merge-specs"
---

# merge-specs

分割された仕様書ファイルを精読・吟味して統合するワークフロー。

## 使い方

```
/merge-specs <ディレクトリ>
/merge-specs <file1.md> <file2.md> ...
```

引数なしの場合は、対象ディレクトリ・ファイルを AskUserQuestion で確認する。

## ワークフロー

### フェーズ1: 精読・分析

対象ファイルをすべて Read して、以下を分析する。

**重複検出**:
- 同じID・同じ機能について別々のファイルで記述されている
- 同じ非機能要件（性能・セキュリティ等）が複数箇所に記述されている

**矛盾・整合性の問題**:
- 同じIDで内容が異なる（どちらが正しいか判断が必要）
- バージョン記述の新旧混在
- 成功基準・受入条件の不一致

**バージョン差異の判定基準**（詳細は `references/merge-workflow.md` 参照）:
- ファイル名・コミット日時・バージョン番号から新旧を判定
- 「既存要件の強化」か「完全新規追加」かを分類
- 既存要件の強化 → ベースファイルの対応セクションに追記/更新
- 完全新規追加 → ベースファイルに新セクションとして追加

### フェーズ2: レポート提示・ユーザー確認

分析結果をユーザーに提示する。レポートには以下を含める:

```
## 統合分析レポート

### 対象ファイル
- <ファイルA> (ベース候補: 最も包括的)
- <ファイルB> (統合元)

### 重複セクション
| セクション | ファイルA | ファイルB | 推奨 |
|-----------|----------|----------|------|
| <機能名>  | 基本記述  | 強化記述  | ファイルBで上書き |

### 矛盾・要確認
- <矛盾がある場合は列挙>

### 統合方針（案）
1. <ファイルA> をベースファイルとして使用
2. <ファイルB> の各要件を以下のように処理:
   - <既存セクション強化> → ベースの該当セクションに追記
   - <新規要件> → ベースに新セクション追加
3. <ファイルB> は統合完了後に削除

この方針でよいですか？
```

AskUserQuestion でベースファイル（dest）の確認を行う。
ユーザーの確認・修正を受けてからフェーズ3に進む。

### フェーズ3: 統合実行

確認済みの方針に基づいて統合を実行する。

**統合の優先順位**:
1. IDが重複する場合 → より詳細・より新しい記述を採用
2. セクションが重複する場合 → 両方の情報を保持しつつマージ（情報の欠落なし）
3. 矛盾がある場合 → ユーザー指定の判断に従う

**編集操作**:
- ベースファイルへの追記・更新は Edit ツールで実施
- 大量変更の場合は変更箇所を明示しながら段階的に実施
- ID番号体系を統一（必要な場合はユーザー確認）

### フェーズ4: 後処理

**吸収済みファイルの削除**:
- 内容がベースファイルに完全吸収されたことを確認
- ユーザーに削除対象ファイルを提示して確認を得る
- 確認後に削除実行

**インデックス更新**:
- 目次・インデックスファイルが存在する場合は更新する

## 判断ロジックの詳細

複雑なケース（IDの重複、大規模マージ、多ファイル統合）については:

→ `references/merge-workflow.md` を参照

## 注意事項

- **情報の欠落厳禁**: マージ時に要件が削除されないよう注意する
- **IDの整合性**: 統合後のIDが重複しないことを確認する
- **ユーザー確認を省略しない**: フェーズ2のレポート確認は必須。自動で削除しない