doc-integrate

doc-integrate: 作業ドキュメントの本体統合と後始末

開発パイプラインの終端で、機能単位の作業ドキュメント docs/dev/<対象>/ の内容を 本体ドキュメント（正式仕様・アーキテクチャ設計書・コンセプト文書など）へ反映し、 反映後に作業ディレクトリを削除する単機能スキル。

作業ドキュメントは開発中の思考の足場であり、開発が終われば読み返されない。 アーカイブして残すのではなく、本体へ吸収してから消すのが本スキルの立場である。

このスキルがやらないこと（重要）

• 他スキルを呼び出さない。前工程（仕様・設計・テスト・レビュー）へは戻らず、 統合と後始末だけを行う。
• ユーザーの承認なしにファイルを消さない・書き換えない。反映方針も削除も、 提示 → 承認 → 実行の順を必ず守る。
• docs/dev/definition-of-done.md を削除しない。これは docs/dev/<対象>/ の外にあるプロジェクト横断の恒久ドキュメントであり、 機能単位の後始末の対象外。パスが似ているため誤削除に最も注意すべき対象である。
• 本体ドキュメントの内容を作業ドキュメントで丸ごと上書きしない。統合は差分の反映であり、 本体側にしかない記述（他機能の仕様・歴史的経緯）を巻き添えで消さない。

パイプライン上の位置づけ

• 本スキルの完了によって docs/dev/<対象>/ が存在しなくなる。 dev-pipeline はこのディレクトリの不在をもってパイプライン終了と導出する （状態ファイルを別途持たず、成果物そのものが唯一の情報源）。
• したがって「統合はしたがディレクトリは残す」という中途半端な終わり方をすると、 下流の導出が終了を検出できない。削除まで完遂するか、統合自体を見送るかのどちらかにする。

起動

/doc-integrate <対象> の形で呼び出される。<対象> は docs/dev/<対象>/ ・ docs/test/<対象>/ と一致するディレクトリ名。

引数が無ければ docs/dev/ 配下のディレクトリ（definition-of-done.md のような 直下のファイルは除く）を一覧して、対象を AskUserQuestion で確認する。

手順 1: 入力の確認（graceful degradation）

docs/dev/<対象>/ を読み、以下の有無を確認する。

入力	用途
spec.md	統合する仕様の本体
basic-design.md	統合する基本設計の本体
pipeline.toml	統合先（[integration] targets）の宣言

• docs/dev/<対象>/ 自体が無ければ、その旨を報告して終了する （既に統合済み、または対象名の誤りの可能性を併記する）。存在しない対象に対して ディレクトリを作ったり、統合を代行したりしない。
• spec.md / basic-design.md はあるものだけを統合対象にする。 片方が欠けていても、あるものだけで統合を進めてよい（欠けている旨は方針提示に明記する）。
• 対象特化の監視設定（test-monitor が構築した CI ワークフロー・ダッシュボード定義・ 計測スクリプト等）があれば、この時点で洗い出しておく（手順 4 で扱う）。

手順 2: 統合先の決定

優先順位 1: pipeline.toml の宣言

[integration]
targets = ["docs/architecture.md"]

[integration] targets があればそれを統合先とする。配列の各要素はリポジトリ相対パス。 宣言されたパスが実在しない場合は、新規作成してよいかを含めてユーザーに確認する。

優先順位 2: 対話で確認

宣言が無い（pipeline.toml が無い / [integration] が無い / targets が空）場合は AskUserQuestion で確認する。訊く前に、リポジトリの docs/ 配下を調べて 統合先の候補を自分で挙げる（正式仕様・アーキテクチャ設計書・README など、 内容の近い既存ドキュメント）。ユーザーに候補を思い出させない。

統合先が本当に存在しない（本体ドキュメントを持たないプロジェクト）場合は、 新規に作るか・統合を見送るかをユーザーに決めてもらう。

手順 3: 統合作業

3-1. 反映方針の提示

編集を始める前に、何をどこへどう書くかを提示してユーザーの承認を得る。 方針には少なくとも以下を含める。

• 統合先ファイルごとに、追加する節 / 更新する既存節 / 削除する記述の対応表
• 作業ドキュメントの記述のうち、本体へ持ち込まないものとその理由 （開発中の検討経緯・却下案・作業メモ・ToDo など、本体の読者に不要なもの）
• 本体側の既存記述と矛盾する箇所があればその一覧と解消方針
• 統合先が複数ある場合、どの内容をどちらへ振り分けるか

作業ドキュメントは「これから作るもの」の記述で、本体ドキュメントは 「今あるもの」の記述である。時制・視点の書き換えが要る点を方針に織り込む （「〜を新設する」→「〜を持つ」など）。

ユーザーの明示的な承認なしに 3-2 へは進まない。

3-2. 編集の実行

承認された方針どおりに統合先ファイルを編集する。

• 統合先の既存の文体・構成・見出しレベルに合わせる（作業ドキュメントの体裁を持ち込まない）。
• 作業ドキュメント内の ID（REQ-# / TC-# / CASE-# など）は、本体ドキュメントの ID 体系に無いものをそのまま持ち込まない。本体側で意味を持たない ID 参照は 平文へ開くか落とす。
• 編集後、統合先ファイルを読み直して、方針で挙げた項目が全て反映されているかと 巻き添えで消えた記述が無いかを自分で確認してからユーザーへ報告する。

手順 4: 監視設定の去就確認

手順 1 で洗い出した対象特化の監視設定（test-monitor の構築物）について、 残すか外すかを AskUserQuestion でユーザーに確認する。

• 残す: 継続的に価値がある計測（回帰検出・カバレッジ監視など）。 対象特化の命名が残る場合は、汎用化のリネームが要るかも併せて確認する。
• 外す: この機能の開発期間だけ必要だった一時的な計測。 外す対象のパス一覧を提示してから削除する。

監視設定が無い場合はこの手順をスキップし、その旨を報告に含める。 docs/dev/<対象>/ の外にある構築物（CI ワークフロー等）は手順 5 の削除では消えないため、 ここで明示的に扱う必要がある。

手順 5: 作業ディレクトリの削除

統合と監視設定の去就が確定したら、docs/dev/<対象>/ を削除する。

削除前チェック（必須）

削除を提案する前に、以下を自分で確認する。

1. 手順 3 の統合が完了し、ユーザーへ報告済みである。
2. 作業ドキュメントにしか無い情報が残っていない。統合対象外と判断した記述を もう一度読み、本当に失って構わないかを確認する（削除後は復元できない）。
3. 削除対象が docs/dev/<対象>/ のみである。 docs/dev/definition-of-done.md が対象に含まれていないことを明示的に確認する。
4. docs/test/<対象>/ は本スキルの削除対象ではない（testing スキル群の成果物であり、 去就は別途ユーザーの判断による）。

承認と実行

削除対象のパス一覧を提示し、AskUserQuestion で明示的な承認を取ってから削除する。 承認が得られなければ削除しない（統合だけ済んだ状態で終わり、 「ディレクトリが残っているためパイプラインは終了と導出されない」ことを報告する）。

手順 6: 終了条件の確認と完了宣言

以下を全て満たしたら 「<対象> のドキュメント統合は完了」と明言して閉じる。 満たしていない項目があれば、何が残っているかを列挙して先へ進めない。

1. 統合先が確定している（pipeline.toml の宣言 or ユーザー確認）。
2. 反映方針がユーザー承認済みで、統合先ファイルへの編集が完了している（手順 3）。
3. 監視設定の去就がユーザー確認済みである（該当が無ければその旨を報告済み）（手順 4）。
4. docs/dev/<対象>/ が削除済みである。または削除しない判断がユーザー承認のもとで 下されており、その旨を報告済みである（手順 5）。
5. docs/dev/definition-of-done.md が残っている（手順 5 の削除前チェック）。

完了報告には、統合先ファイルの一覧・削除したパスの一覧・ 監視設定の去就を含める（後から何が起きたか追えるようにする）。

用語

• 作業ドキュメント: docs/dev/<対象>/ に置く機能単位の一時ドキュメント （spec.md / basic-design.md / pipeline.toml）。統合後に削除する。
• 本体ドキュメント: プロジェクトに恒久的に置かれるドキュメント （正式仕様・アーキテクチャ設計書・コンセプト文書など）。統合先になる。
• 恒久ドキュメント: 機能単位の削除対象に含まれないドキュメント。 docs/dev/definition-of-done.md が該当する。