| 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: 統合実行
確認済みの方針に基づいて統合を実行する。
統合の優先順位:
- IDが重複する場合 → より詳細・より新しい記述を採用
- セクションが重複する場合 → 両方の情報を保持しつつマージ（情報の欠落なし）
- 矛盾がある場合 → ユーザー指定の判断に従う
編集操作:
- ベースファイルへの追記・更新は Edit ツールで実施
- 大量変更の場合は変更箇所を明示しながら段階的に実施
- ID番号体系を統一（必要な場合はユーザー確認）
フェーズ4: 後処理
吸収済みファイルの削除:
- 内容がベースファイルに完全吸収されたことを確認
- ユーザーに削除対象ファイルを提示して確認を得る
- 確認後に削除実行
インデックス更新:
- 目次・インデックスファイルが存在する場合は更新する
判断ロジックの詳細
複雑なケース（IDの重複、大規模マージ、多ファイル統合）については:
→ references/merge-workflow.md を参照
注意事項
- 情報の欠落厳禁: マージ時に要件が削除されないよう注意する
- IDの整合性: 統合後のIDが重複しないことを確認する
- ユーザー確認を省略しない: フェーズ2のレポート確認は必須。自動で削除しない
