Swift-Selena: Skill for Claude Code

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のレポート確認は必須。自動で削除しない