메뉴
2 つの仕様ディレクトリ（基本 DIR と追加 DIR）を 1 つに統合する。 追加側を正とし、基本側を追加側の内容に合わせて修正したうえで、追加側に残る純粋新規部分のみを基本側へ移し、追加 DIR を削除する。 内容単位（節・項目）で処理し、ファイル単位の単純コピーではない。 トリガー: "仕様 DIR をマージ", "spec をマージ", "merge spec", "追加仕様を基本に統合", "spec ディレクトリ統合"
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
msg-sys 通信基盤（常駐 Codex セッションとの Stop フック経由の非同期往復）の上で、 Codex とのレビュー依頼・所見受領・修正・完了判定を駆動する。3モード（依頼/受信/再開）を持つ。 依頼モードのトリガー句: "msg-reviewでレビュー依頼", "Codexとレビュー往復したい", "常駐Codexにレビューを依頼", "msg-reviewを実行して", "Codexセッションにコードレビューを頼みたい"。 受信モードの起動契機（トリガー句ではなくメッセージ本文の形式で成立）: Stop フックが差し戻した メッセージ本文の先頭が `[msg-review] <種別> review_id=<review_id> round=<n>` である。 再開モードのトリガー句: "msg-reviewを再開したい", "レビューの往復上限到達通知が来た、状況を確認して", "review_idの未解決所見を要約して", "msg-reviewの続きを確認したい"。
設計書から実装戦略を策定し、タスクを抽出して YAML 計画書を作成・更新する。レビュー+自動修正→commit まで一貫実行。 トリガー: "計画書作成", "計画開始", "start plan", "start planning"
計画書からタスクを選び、実装・レビュー・計画更新まで一貫して実行する。 トリガー: "実装開始", "タスク実行", "start implement"
コード・文書をレビューし、品質問題の発見から修正まで自動化できる。重大度 🔴🟡🟢 で分類。 --auto で修正まで一貫実行。code/requirement/design/plan/uxui/generic の6種別に対応。 トリガー: "レビュー", "review", "レビューして", "確認して"
GitHub Issue を軽量実装で進めるか forge の SDD フロー（start-requirements/start-design/start-plan）に委ねるかを判定するスキル。feature namespace の要否も判定する。トリガー：「このIssueをトリアージして」「Issueの進め方を判定して」「#N はどう進めるべきか判定して」
GitHub Issue の実装を準備から完了まで一貫して行う。triage の判定調査結果（仕様書・ルール・類似PR・既存コードの特定）を引き継ぎ、実装計画の策定・Issue への解決内容記載・実装・レビューまで進める。UI Issue の場合は Figma デザイン仕様書・実装設計書の作成、UI 実装、実装レビューまでカバーする。 `/anvil:triage-issue` が軽量実装と判定した Issue に対して Skill ツール経由でのみ起動される（ユーザーからの直接起動は不可）。
| name | merge-specs |
| description | 2 つの仕様ディレクトリ（基本 DIR と追加 DIR）を 1 つに統合する。 追加側を正とし、基本側を追加側の内容に合わせて修正したうえで、追加側に残る純粋新規部分のみを基本側へ移し、追加 DIR を削除する。 内容単位（節・項目）で処理し、ファイル単位の単純コピーではない。 トリガー: "仕様 DIR をマージ", "spec をマージ", "merge spec", "追加仕様を基本に統合", "spec ディレクトリ統合" |
| user-invocable | true |
| argument-hint | [base] [additional] # 短縮名なら specs/ 配下を自動探索 |
| allowed-tools | Bash, Read, Edit, Write, Glob, Grep, AskUserQuestion, Skill |
2 つの仕様ディレクトリを統合するための skill。追加側を正とし、内容レベル（節・項目単位）で基本側を修正したうえで、追加側に残る純粋新規部分のみを基本側へ移し、追加 DIR を削除する。
| 記号 | 意味 |
|---|---|
| 基本 DIR (A) | 統合先となる主仕様ディレクトリ。最終的にここに全てが集約される |
| 追加 DIR (B) | 補助仕様ディレクトリ。基本側と異なる箇所は追加側が正とする |
| A' | 追加側に従って基本側を修正したあとの状態 |
| B' | 追加側から「基本に取り込まれた部分」を取り除いた、純粋に新規の部分のみ |
ファイル単位ではなく 内容単位 で処理する。1 ファイル内に「基本修正に使う部分」と「純粋新規の部分」が混在しうる。
文書 A（基本）: X, Y を含む
文書 B（追加）: X', Z を含む
概念上の状態遷移:
- A の X を、X' の趣旨に沿うよう改訂 → A' = (X', Y)
- B のうち基本に取り込んだ部分を除いた残り = B' = (Z のみ)
- B' を基本 DIR へ新規作成
結果: 基本 DIR = A' + B' （= Y, X', Z）
追加 DIR = 最後に丸ごと削除（書き換えはしない）
git rm -r でディレクトリごと削除する基本側への反映は コピペ禁止。プロの文書改訂として、以下を毎回考慮する。
改訂作業中に迷ったら、次の問いに答える形で判断する:
これらに「Yes」と言えるまで改訂は終わらない。反映=完了ではなく、改訂後の文書品質が基本側既存ファイルと同等以上であって初めて完了。
/merge-specs <base> <additional>
specs/ をハードコードしてはいけない。プロジェクトごとに仕様格納場所は異なるため、引数は
短縮名 / 相対パス / 絶対パス いずれも受け付け、${CLAUDE_PLUGIN_ROOT}/skills/doc-structure/SKILL.md
の「spec ルート・短縮名の解決」手順に従って base・additional それぞれを実ディレクトリへ解決する。
.doc_structure.yaml が無い、候補ディレクトリが存在しない 等）→ AskUserQuestion で
正しいパスを聞く呼び出し例（このプロジェクトでは .doc_structure.yaml の specs.root_dirs が specs/*/... のため spec ルート = specs/）:
/merge-specs main review_window # → specs/main, specs/review_window
/merge-specs specs/main specs/review_window # 明示パスも可
/merge-specs /abs/path/A /abs/path/B # 絶対パスも可
別プロジェクトで .doc_structure.yaml の specs.root_dirs が docs/specifications/*/... なら、spec ルート = docs/specifications/ として同じ短縮名指定が機能する。
git status --short
git rev-parse --abbrev-ref HEAD
本 skill は forge の 追加開発ワークフロー（additive_development_spec.md §4「merge タイミングと手順」）の merge ステップを担う。追加開発で作られた一時文書は frontmatter に type: temporary-feature-* を持つ（temporary-feature-requirement / temporary-feature-design）。
追加 DIR (B) の各 *.md 先頭 frontmatter を確認し、判定する:
# 追加 DIR 内に temporary-feature 文書が含まれるか
grep -rlE '^type:[[:space:]]*temporary-feature-' "$additional_dir" 2>/dev/null
additive_development_spec.md §2 の優先度（追加開発の要件定義書が最優先＝正）と本 skill の「追加側が正」原則は一致する。Phase 8 の一括削除も §4「一時文書の削除」と整合する。安心して進めてよい。この判定は安全確認のための任意検証であり、
temporary-featurefrontmatter を必須とはしない。検出有無にかかわらず処理フロー自体は変わらない。検出されない場合に「追加側を正」「最後に追加 DIR を削除」という破壊的前提でよいか不安があれば、Phase 8 の削除前確認（8.1）で改めてユーザーに確認する。
基本 DIR (A): {base-dir}
追加 DIR (B): {additional-dir}
作業ブランチ: {current-branch}
モード: {追加開発モード（temporary-feature 検出） / 汎用マージモード}
「追加側を正」「内容単位で統合」「追加 DIR は最終的に削除」の方針で進めます。
Phase 4 / 5 の改訂・新規作成は「改訂の原則」に従うプロの文書改訂であり、ターゲットプロジェクトの文書規約に沿わせる必要がある。規約の所在はプロジェクトごとに異なるため、特定の文書名をハードコードせず、利用可能な検索スキルで動的に取得する。
判断材料となる規約の例:
取得手順（利用可能なものを使う。無ければスキップ）:
1. プロジェクトの仕様・ルール検索スキルが利用可能か確認する
（例: /query-specs · /query-rules · /forge:query-db-specs · /forge:query-db-rules · /forge:query-forge-rules）
2. 利用可能なら、上記「規約の例」をキーワードに検索し、ヒットした規約文書を Read して改訂の指針に取り込む
（例: 「要件 設計 境界」「要件定義書 フォーマット」「設計書 フォーマット」「文書 スタイル」）
3. 検索スキルが一つも無い場合は取得をスキップし、改訂の原則 §6.2 に従って
**基本側 (A) の既存文書から文体・粒度・章構成・フォーマットを推測**して合わせる
取得した規約はあくまで改訂の指針であり、merge の処理フロー自体は変えない。検索結果が基本側の実態と矛盾する場合は、改訂の原則どおり基本側の慣習を優先する（基本 DIR が正本だから）。
両 DIR のファイルを取得し、対応関係を表にする。
find "$base_dir" -type f -name "*.md" | sort
find "$additional_dir" -type f -name "*.md" | sort
各追加ファイルを以下に初期分類する:
| 分類 | 条件 | 一次扱い |
|---|---|---|
| (α) 同名/同 ID あり | 基本側に同名または同 ID のファイルが存在 | 内容比較対象。Phase 2 で diff を取る |
| (β) 同名/同 ID なし | 基本側に対応ファイル無し | 新規候補。ただし内容に基本側を直す指示が混ざる可能性あり、Phase 2 で本文を読む |
初期分類はあくまで入口の振り分け。最終的な処理は Phase 2 の内容解析で決まる。
追加 DIR のファイル分類:
(α) 基本側に対応あり (内容比較対象):
- {path1} ←→ {base/path1}
...
(β) 基本側に対応なし (新規候補):
- {path2}
...
追加 DIR の各ファイルを読み、内容を 2 種に分ける:
| 種別 | 定義 | 行き先 |
|---|---|---|
| (i) 置換指示 | 基本側の既存記述（X）を別形（X'）に置き換える内容 | 基本側へ反映 (Phase 4) |
| (ii) 純粋新規 | 基本側に対応物が無い、純粋に新規の概念・仕様（Z） | 追加側に残る (= B' の構成要素、Phase 6 で基本へ移動) |
追加側の文や節について、以下を満たすものは (i) と判定:
特定後、影響範囲表 を作成:
追加側の記述 → 影響する基本側ファイル / 節
{追加ファイル:行/節} → {基本ファイル:行/節}
...
(i) でない部分は (ii)。追加側のみに存在する概念・仕様。
基本側に同 ID 文書が存在し、追加側がその全面改訂版である場合、ファイル全体が (i) となり、基本側を追加側で置換するのが妥当。これは Phase 4 で「ファイル単位の置換」として扱う。
Phase 2 で抽出した (i) の各項目について、自動処理可否を判定する。
plan/ の扱いなど）明白でない案件は 一括の判定表 として Markdown で提示し、まとめて回答してもらう。1 件ずつ AskUserQuestion で往復しない。
以下、判定が分かれる案件です。各行に番号で回答してください:
| # | 追加側 | 基本側 | 提案 | 選択肢 |
|---|---|---|---|---|
| 1 | DES-016 §3 ウィンドウ統一 | DES-001 §5 | 基本側を追加に置換 | (a) 提案通り / (b) 基本側を残す / (c) 統合 |
| 2 | ... | ... | ... | ... |
Phase 2 (i) + Phase 3 の判定に基づき、基本側を 改訂 する。コピペ禁止。「改訂の原則」に従い、プロの文書改訂として作業する。
各 (i) 項目について、以下の手順を踏む:
基本側に同 ID 文書があり、追加側がその全面改訂版である場合でも そのまま上書きコピーはしない。以下を確認する:
実装手順:
単純な
cpやgit mv -fでの上書きは原則として避ける。やむを得ず実施するなら、その判断理由を Phase 9 の完了案内に記す。
改訂に伴い ID 改廃・節番号変更・用語変更が発生した場合、その参照を全文書で更新する:
git ls-files -z '*.md' | xargs -0 grep -nE '{旧 ID|旧パス|旧用語}' 2>/dev/null
該当箇所を Edit で書き換える。書き換え後、参照先文書の改訂内容と整合するかも併せて確認。
各改訂単位（節 / ファイル）の作業完了時、自問する:
すべて「Yes」になるまで改訂は終わらない。
論理的な改訂単位ごとに 1 コミット推奨（ロールバック容易化）。コミットメッセージには改訂の趣旨を書く（単に「reflect additional」では不可）。
追加側 (B) のファイルは一切書き換えない。B' は基本側に 新規ファイルとして作成 する（または基本側既存ファイルへの改訂として取り込む）。B 側で Edit / git mv / git rm は行わない（削除は Phase 8 で一括）。
Phase 2 の内容解析で、追加側の各ファイルは以下のいずれかに分類されている:
| 種別 | 内容構成 | Phase 5 の処理 |
|---|---|---|
| type-i: 全体が (i) | 追加側全体が基本側の改訂指示 | Phase 4 で改訂済み。Phase 5 は何もしない。B 側ファイルはそのまま残し、Phase 8 で削除 |
| type-ii: 全体が (ii) | 追加側全体が純粋新規 | 基本側に新規ファイルとして Write で作成（読み込み元: B 側ファイル本文。改訂の原則に従い、基本側文体に馴染ませて書く） |
| type-mix: (i) と (ii) が混在 | 一部は基本改訂指示、一部は純粋新規 | Phase 4 で (i) 部分を基本に改訂反映済み。(ii) 部分のみ基本側に新規ファイルとして Write で作成 |
plan/、基本側に plan/ 無し）が必要なら新設基本側に同 ID 文書があり、追加側がその全面改訂版だった場合（type-i 相当）、Phase 4.2 で基本側既存ファイルを Write で書き直し済み。Phase 5 ではその B 側ファイルに対しては何もしない（Phase 8 で削除）。
新規作成したファイル内で、基本側の他文書を参照する箇所は基本側の相対パス・ID に合わせる（B 側内部の参照のままにしない）。
Phase 4 / 5 の作業で発生した、文書間参照・ID 体系・用語の整合を最終確認する。
git ls-files -z '*.md' | xargs -0 grep -nE '{改廃された ID|旧用語|旧パス}' 2>/dev/null
該当箇所を Edit で書き換える。
Phase 5 で新規作成したファイル内の参照先（[..](path) や ID 参照）が、基本側に実在することを確認:
grep -oE '\[.*\]\([^)]+\.md\)' <新規作成ファイル> # リンクを抽出
grep -oE '[A-Z]+-[0-9]+' <新規作成ファイル> # ID 参照を抽出
参照先が存在しない場合は、参照を修正するか、参照先が必要なら別途作成。
# 例: DES-XXX_*.md の番号一覧
git ls-files "$base_dir/design/DES-*.md" \
| sed -E 's|.*/DES-([0-9]+)_.*|\1|' | sort -n | uniq -c | sort -nr | head
重複があれば即修正。欠番は基本 DIR の慣習次第（許容/不可をユーザー確認）。
# 文書内の [..](path) や ID 参照を抽出して、参照先の存在を確認
git ls-files -z '*.md' | xargs -0 grep -nE '\[.*\]\([^)]+\)|[A-Z]+-[0-9]+'
参照先が消えている / 改名されている場合は Edit で更新。
プロジェクトに ToC（.claude/doc-advisor/ 等）が存在する場合は、その再生成案内を Phase 9 で行う。本 skill では再生成しない。
仕様ドキュメントの変更がコード生成・テストに影響しうるプロジェクトでは、プロジェクト固有のビルド・テストコマンドで影響確認。
Phase 7 の検証がすべて通ったら、追加 DIR を丸ごと削除 する。
Phase 4 / 5 で追加側ファイルは一切書き換えていないため、追加 DIR には元の B 側ファイルがそのまま残っている。これらは:
よってまとめて削除して問題ない。
削除対象を表示してユーザー確認:
find "$additional_dir" -type f -name "*.md" | sort
echo "---"
echo "上記 $(find "$additional_dir" -type f -name "*.md" | wc -l) ファイルを含む $additional_dir を削除します"
AskUserQuestion:
追加 DIR を削除しますか? (Phase 7 の検証は通過しています)
- はい、削除する (Recommended)
- 中断 (削除前にもう一度確認したい)
Phase 0.3 が汎用マージモード（
temporary-featurefrontmatter なし）だった場合、削除対象が一時文書である裏付けが無い。ここで削除対象の一覧を改めて提示し、本当に削除してよいかを念入りに確認する。
git rm -r "$additional_dir"
git status --short
削除以外の差分が出ていないか確認する。
{additional_dir} を {base_dir} に統合しました:
基本側の修正 (Phase 4): N 件
追加側からの新規移動 (Phase 6 mv): N 件
追加側のファイル単位置換 (Phase 6 -f): N 件
追加側の削除 (Phase 6 rm): N 件
検証結果:
ID 重複: なし
リンク切れ: なし
次のステップ:
- ToC 再生成: /forge:update-db-specs （該当プロジェクトのみ）
- ビルド確認: プロジェクト固有のビルドコマンド （該当プロジェクトのみ）
- commit: 各 Phase で小コミット済みなら、最後の差分のみ commit
additive_development_spec.md — 追加開発ワークフロー仕様。本 skill はその §4「merge タイミングと手順」の実装にあたる。追加 DIR (B) が type: temporary-feature-* を持つ一時文書である場合、§2 の優先度（追加開発の要件定義書が正）と本 skill の「追加側が正」原則が一致する。Phase 0.3 で frontmatter を任意検証するWhat/How 境界・要件/設計/計画のフォーマット・文書品質の規範（
spec_design_boundary_spec/*_format/*_principles_specなど）は、特定の文書名をハードコードせず Phase 0.5 で検索して取得する。本 skill は汎用ツールであり、ターゲットプロジェクトごとに規約の所在・内容が異なるため、固定リンクは持たない。