close-plan

計画を締めくくる

ユーザー向けの小さな機能について、一連の作業を締めくくります。PLAN.final.md は承認され、実装も完了しており、docs/<feature>/（プロジェクトの計画用 フォルダー。別の場所を使っている場合はその場所）には、そこに至るまでの改訂版、 メモ、実行成果物が保存されています。そのままにしておくと、次のエージェントが 最初に読み、最も信頼するものになってしまいますが、その大部分はもはや事実では ありません。

新しいエージェントがツリーだけを読んで、この機能の実情を最少の手順で把握できるか、 そして計画で約束したすべてのフェーズを、完了、引き継ぎ、延期、またはユーザーの 判断による取り下げとして、引き続き確認できる状態にできるかで評価されます。

自分の判断で作業を取り下げてはいけません。 最終版のドキュメントで約束した フェーズは、製品上の約束です。完了していない場合は、ユーザーが別の指示をしない 限り引き継ぎます。ユーザーが別の指示をした場合は、その理由とともにプロジェクトの 延期作業記録に記載します。

記録する際に、新たな判断を下してはいけません。 すでに下された判断を文書化する のがあなたの役目です。新たな判断を下すことではありません。

このスキルについて

• このスキル — PLAN.final.md が1つ、フェーズがいくつかあり、いくつかの領域に またがる機能です。完了した内容の大半は、すでに存在するページに記載します。
• close-roadmap — マイルストーンのロードマップ、 ドキュメントフォルダーを独立して持つほど大きな機能、ナビゲーション用の表となる README、ロードマップのレビューサイクルに再び入る V2 ロードマップが対象です。

境目はフェーズの数ではなく、その機能に独立した恒久的なドキュメントが必要かどうか です。この計画を締めくくることで、フォルダー README、アーキテクチャページ、 3つの判断記録を作成することになるなら、締めくくるのはロードマップです。 切り替えてください。既存の領域ページにセクションを追加し、判断記録を1つ作成する 程度なら、このスキルの対象です。

入力

機能名は引数から取得します（例：/close-plan spell-check）。 docs/<feature>/ の内容をすべて読み、次のものを確認します。

1. PLAN.final.md（存在する場合は TECHNICAL.final.md も）。改訂版しか 存在しない場合は、そこで中止します。承認されたものがないため、締めくくる対象も ありません。
2. 実行記録 — EXECUTION.md、質問ログ（未解決の質問をプロジェクトが保存している 場所）、ACCEPTANCE.md、HANDOFF.md、および未テスト項目の一覧。これらにあるのは 事実ではなく、主張です。
3. コードと履歴。 ブランチの git log と、EXECUTION.md が参照するコミットを 確認してから、ドキュメントで完了とされているすべてのフェーズについてコードを 調べます。検証手順に記載された動作をコードが実現している場合に限り、その フェーズは完了です。ドキュメントに完了したと書かれているだけでは不十分です。
4. この機能が関係するページ — プロジェクトのドキュメントマップ（例： AGENTS.md や CONTRIBUTING.md の表）が、それぞれの種類の内容の記載先として 示すページです。ページに追記する前に読み、内容が重複するのではなく、関連する 記述の隣に追加されるようにします。

同種のスキルと同様に、メイン統合ブランチとの差分を確認します（git fetch を実行し、 続いて git log --oneline <branch>..<main> を実行します。<main> は main や dev などです）。その後にツリーが変更されている状態で締めくくると、もはや存在 しない状態を記録することになります。

受け入れレビュー

close-roadmap の指定どおり、ACCEPTANCE.md の各項目を 一つずつ確認します。それぞれを合格（根拠を示して記録）、不合格 （フェーズは未完了）、または未実施（確認を求める。回答が得られるまでフェーズは 未完了）として扱います。未実施の確認項目は未検証の作業です。コードを読むだけでは 判断できないために一覧に含まれていたのであり、今コードを読んでも判断できません。

トリアージ — ファイルに触れる前に、内容を復唱する

計画の各フェーズ、質問ログの各項目、未テスト項目の各項目には、close-roadmapの表にある4つの扱い — 完了、保留、延期、取り下げ — のいずれかを割り当てます。後ろの2つを決めるのはユーザーだけという同じルールに従います。表（フェーズ、タイトル、扱い、根拠）にまとめ、回答が必要な質問には印を付け、何かを削除する前にユーザーの返答を待ってください。 この台帳はコミットメッセージに記載します。ツリーから再構成できない唯一の出力です。

短くまとまることが多いため、この台帳は別の文書ではなく、レポート自体に記載できる場合がほとんどです。

まだ残っている作業

• まとまった残作業 → docs/<feature>/<STEM>-V2.rev1.md。最終文書のステムに合わせて命名します — PLAN.final.md は PLAN-V2.rev1.md に引き継ぎます — build-featureがrev1を作成する方法で記述し、execute-planで実装する前にreview-docのサイクルに再度入ります。「ここから再開」で書き始め、最終文書にある継続中の要件と不変条件をコピーして引き継ぎます（削除予定のファイルへのリンクは決して作成しません）。保留中の各フェーズについて、現在のコードに合わせて書き直した入力、出力、検証手順を記載します。
• 1、2件の小さな残作業 → プロジェクトの技術的負債の記録またはバックログ、あるいは領域ページの「新しい作業の移行先」メモに記載します。残作業が1件だけのV2 rev1を作るのは形式だけの儀式であり、ロードマップとして読まれてしまいます。そのために文書を作成しないでください。
• ログに残った未回答の質問は、記録済みの選択肢と推奨案とともにrev1の未解決のプロダクト上の質問にします。回答済みの質問は決定事項です。プロジェクトで決定記録を管理している場合は、そちらに記載します。

完了した作業 — 新たなページを作らず、既存の文書に統合する

プロジェクトのドキュメントマップに従って各項目の移行先を決め、それぞれの移行先についてclose-roadmapのルールに従います（決定事項は決定記録に、モデルはデータモデルページに、ユーザーが行うことはユーザーガイドに、現在機能する内容はプロダクトのステータスページに記載します。完了と部分完了の違いを正直に示し、未検証のまま受け入れられたフェーズは部分完了とします）。生成されたファイルを手作業で編集するのではなく、ドキュメント生成ツールを実行してください。

この規模では、まず既存ページに記載するのが原則です。 計画内の完了した作業は、新しいページではなく、既存ページに段落として追記します。小さな機能ごとに新しいファイルを作ると、ドキュメントツリーは際限なく膨らみ、将来の読者はそのたびに余計なページを確認することになります。docs/<feature>/にファイルを作成するのは、その機能だけに関する内容で、共有ページに収めるには長すぎる場合に限ります。

フォルダーが不要な機能のために、フォルダーを残してはいけません。 すべての完了した作業を共有ページに記載し、残作業がなければ、docs/<feature>/全体を削除します（notes/に保存する価値のある理由が記されている場合に限り、履歴として明記したうえで残します）。記録は共有ページに任せます。フォルダーを削除することを台帳に記載し、ユーザーに分かるようにしてください。

フォルダーを残す場合は、README.mdが必要です。機能の説明を1文、簡潔なナビゲーションテーブル、新しい作業の移行先を記載します。close-roadmapのREADME全体を置く必要はありません。計画単位のフォルダーに4つのセクションは不要です。

ツリーから不要になったものを削除する

ユーザーが台帳を承認し、ドキュメントの作成が完了したら、PLAN.final.md、すべての .revN.md と .revN.notes.md、EXECUTION.md、機能の質問ログ、ACCEPTANCE.md、HANDOFF.md、および未テスト項目のリストを削除します — 再実行する価値のある受け入れ確認項目が残っている場合は、まず機能の現行テスト計画に移します。各ラウンドの完了時にコミットしてあるため、履歴は Git に残っています。ツリー内にコピーがあると、エージェントはそれを最新のものと誤認します。archive/ フォルダーは作成しません — パスが長くなっただけの削除です。コミットメッセージには、削除した各ファイルと、その内容の移動先を記載します。

すべての参照元リンクを修正します。 削除または名前を変更したパスごとに、ドキュメント、エージェント向けのオリエンテーションファイル、README、ソースツリーを grep で検索します — ソースファイルがドキュメントを名前で参照していることもあります。リンクチェッカーがない場合は grep がリンクチェックになるため、最後の名前変更の後に実行します。

仕上げ

• 完了内容を1つの変更としてコミットします。commit-changes に従い、台帳、作成した内容とその配置先、削除したものとその内容の移動先を記載します。依頼がない限り、プッシュはしません。
• 製品の観点からユーザーに報告します：機能が現在どのように動作するか、未対応事項、完了時にユーザーが決定した内容、そして — いずれかのフェーズがテストスイートの成功ではなく担当者の確認をもって完了した場合は、そのフェーズを報告します。