wrap-up (クローズ処理)

Wrap-up（クローズ処理）

ユーザーがこのチャットをアーカイブしようとしています。会話の中にしか存在しないもの（決定事項、ディスク上の変更、次セッションが引き継ぐべきもの）が失われようとしています。インストールされているいくつかのスキルが、それぞれその一部を保存します。このスキルの役割は、それらを発見し、正しい順序で実行し、1回の確認で停止することです。

スキルのセットは固定ではありません。プラグインは追加されたり削除されたりし、ユーザーは新しいスキルを作成します。スキル名をハードコードせず、毎回インストールされているものから動的に発見し、references/close-out-catalogue.md のカテゴリと照合してください。カタログには各カテゴリの内容、順序、コストが定義されています。このファイルは各環境での実行方法を定義します。両者に矛盾がある場合は、カタログの「何を」「どの順序で」を優先し、このファイルの「どのように」を優先し、矛盾点をレポートに記載してユーザーがカタログを修正できるようにしてください。

0. 現在地とセッションの古さを把握する

以下の大部分は環境とセッションの経過時間によって変わります。そのため、まず両方を確定し、それらを計画の先頭に1行で記載してください。3つの環境があります:

• ユーザーマシン上の Claude Code。 そのマシン上のシェル、~/.claude/skills 内のスキル、実行されるフック（設定されていれば各セッションを記録する SessionEnd フックも含む。ローカルマップまたは settings.json でその有無が示されます）、ディスク上のリポジトリと保管庫。以下のすべてがそのまま適用されます。
• デバイスシェルを持つ claude.ai またはクラウドセッション。 チャットは Linux コンテナで実行されますが、ユーザーのコンピュータ用のシェルツールがリストされているため、コマンドはそこ（ユーザーが接続したフォルダ内）で実行されます。接続されたフォルダ内の保管庫やスクリプトにアクセス可能です。このスキル自身のファイル（カタログ、scripts/）はコンテナ内にあり、そのマシン上にはありません。フックは実行されません。メモリはメモリツールを介し、バックグラウンドパスが各ターン後に永続的なファクトを保存します。
• デバイスシェルを持たない claude.ai またはクラウドセッション。 ユーザーのコンピュータ上のファイルには、ファイルをコンテナにステージングして戻すツールを介してのみアクセス可能で、デスクトップアプリがリンクされている場合に限ります。それ以外の場合、ユーザーのディスク上のものにはアクセスできません。フックとメモリは上記と同様です。

シグナル：プラットフォームとワーキングディレクトリ、リストされているツール（デバイスシェル、デバイスファイルツール、メモリツール）、システムプロンプトがメモリとプロジェクトについて何を言っているか。判断できない場合は、その旨を述べて質問してください。間違った推測は間違った場所に書き込むことになります。

次に、経過時間。クローズは通常作業終了時に要求されますが、チャットは何日も開いたままで、後から他のセッションが同じファイル、ノート、スキルで作業した後に閉じられることがあります。セッションは、そのセッションが触れたもののいずれかが、その最後の実際の作業よりも後に変更された場合にstale（古い）とみなされます。その作業の日付（会話のタイムスタンプまたは日付付きノート）と、それが触れたファイルやストアエントリの更新日時、後のコミット、後の日付のストアエントリ、またはリストに表示されなくなったか名前が変わったスキルを比較してください。1つの変更で十分です。経過時間自体は調査の理由であって、断定ではありません。誰も利用していない1週間前のチャットはstaleではありません。ギャップとともに最上行に記載してください（「最終アクティブ: 11月4日、触れたファイルはその後変更されています」）。

stale セッションでは、ディスクとストアは会話よりも新しいため、それらが優先されます:

• 書き込みを計画する前に、そのステップが触れる各ファイルとストアエントリの現在のバージョンを読み、会話が記憶している内容ではなく、現在の状態に基づいて計画を立ててください。
• そのセッションが下した決定で、後のセッションが既に記録しているものは完了とみなします。それを指摘し、再度書き込まないでください。後のセッションが変更または破棄した決定は、このクローズで復元するものではありません。破棄されたものとして名前を挙げ、スキップしてください。後の記録が決定の一部のみをカバーしている場合、またはどの程度カバーしているか不明な場合は、明確にカバーされている部分のみを破棄し、残りを「破棄された可能性がある」と名前を付けます。そのどちらになるかは、単一の質問に委ねられます。
• セッションが使用したパス、名前、スキルは移動または名前変更されている可能性があります。使用する前に毎回再解決してください。新しい形式は、それ以降に何かがそれを示している場合にのみ考慮されます（メモリ、ノート、コミット、スキル自身の説明で以前の名前が示されている場合）。その形式を使用し、その旨を明記してください。何も示されていない場合は、推測せずに古い名前を「解決不能」とし、現在のものとしてストアに書き込まないでください。
• 提案すべき残りは、セッションが決定したもので、それ以降に記録、変更、矛盾が生じていないものだけです。それは非常に少ない可能性があります。1行または何も書き込まない stale クローズも正しいクローズです。

同じチャットに、ユーザーが作業を続けた前に実行された以前のクローズが既に含まれている場合があります。その場合、このクローズは最初からやり直すのではなく、そのクローズを基に構築します。その計画を取得し、各ステップを完了済み（そのレポートがそう述べ、ディスクも同意する）、破棄済み、または未処理としてマークし、その後に起こったことだけを確認してください。以前のクローズが提案したがユーザーが回答しなかった計画は承認されていません。その未処理のステップをこの計画に引き継ぎ、再度ディスクと上記のルールに対して確認し、実行したり黙って破棄したりせず、最上行に以前のクローズが存在することを記載してください。

1. 発見

発見を開始する前に、環境の常時指示（Claude Code では CLAUDE.md ファイルと自動メモリ（ここでは常時とみなす）、claude.ai ではプロジェクト指示、ユーザーの設定とメモリ、およびこの SKILL.md のパッケージコピーが保持する可能性がある「このインストールのローカルマップ」セクション）で、このルーチンのローカルマップを確認してください。これは、各カテゴリをカバーするインストール済みスキル、ストア、退役済みのもの、測定されたコストを指定する短いセクションです。存在する場合、それは発見を置き換えます。指定された各スキルがまだインストールされていることを確認し（名前付きコマンドまたはパスを安価な読み取り専用で確認できる場合はそれを利用）、退役済みとされたものは解決済みとして扱います。部分的なマップ（ストアや退役は指定されているが、カテゴリごとのスキルはない）は、発見を置き換えるのではなく情報として利用します。指定されたものを尊重し、残りを発見し、セクション5のオファーは2番目のセクションを追加するのではなく、そのセクションを完了することになります。何も存在しない場合は、以下のように発見し、最後にマップを書き込むオファーを出します（セクション5）。Claude Code では、CLAUDE.md ファイルをコンテキストだけでなくディスクからも読み取ってください。コピーが注入されていると編集より古い可能性があり、古いものは完全な発見と既存のマップの上に2番目のマップを書き込むオファーにつながります。

候補リストは、コンテキスト内にある available skills のリスト（名前＋説明）です。これはローカルスキル、プラグインスキル、gstack などをすべてカバーします。これより優れた情報源はありません。リストの2つの特徴：スキルがプラグインプレフィックスありとなしで表示され、説明が同じ場合、それは1つのスキルです。そのため、計画ではベアネームで呼びますが、実行時はリストに表示されている正確な名前で呼び出します。また、リストは実行中に、独自のスキルを持つフォルダにコマンドが触れると増加することがあり、その遅れて到着したスキルは、カテゴリに一致する場合にのみ計画を変更します。

references/close-out-catalogue.md を読み取ってください。定義されている各カテゴリについて、説明がその目的に一致するインストール済みスキルを選択してください。既知のメンバーはヒントであり、答えではありません。リストにないインストール済みスキルでも、説明が適合すれば対象となります。リストにあるがインストールされていないものはスキップされます。カタログがフラグを立てているニアミスに注意してください。リストに名前のみでスキルが表示されている場合（両方の環境でこれが発生します）、名前とカタログの「認識方法」の単語で照合し、計画に「(説明なし)」とマークして、ユーザーが照合が弱いことを認識できるようにします。

インストール済みスキルがないカテゴリは、計画に「スキップ、未インストール」として記載します。代わりを即興で作らないでください。ただし、環境がそのジョブのための独自のメカニズムを持っている場合を除きます（セクション2）。一部のカテゴリはスキルではありません（Claude Code では、自動メモリは Write ツールで書き込まれ、グラフ更新はコマンドです）。これらは同じ計画内のステップであり、環境がそれらを持っている場合のみです。

次に、このセッションで実際に実行する価値があるものを確認します:

• グラフ。 マシン上の Claude Code では、python scripts/find_graphs.py <workspace-root> を実行します（パスはこのスキルのディレクトリからの相対パス。どの Python でも動作します）。ワークスペースルートはセッションの作業フォルダ、またはプロジェクト指示がすべてのリポジトリを保持すると説明しているより広いフォルダです（その場合）。スクリプトは、プロジェクトフォルダがその下の最大5レベルにあるすべての graphify-out/ をリストし、マニフェスト以降にファイルが変更されたかどうかを示します。グラフごとに1行、CURRENT、STALE（変更数と削除数を含む）、UNKNOWN（マニフェストがない、または graphify がインポート不可）、または「見つかりませんでした」という1行です。カウントは、変更がノート（再抽出に約85kトークン）かコード（LLM不要）かを区別しません。セッションが触れたものから判断して明記してください。CURRENT はステップではありません。グラフ化されたファイルを編集したことを覚えていても、マニフェストはその後にグラフが再構築されたかどうかを認識します。マシンに Python がない場合、グラフは未確認です。その旨を述べてください。他の場所では、スクリプトはワークスペースを参照できません（コンテナ内で実行され、グラフはユーザーのディスク上にあります）。すべてのグラフを「未確認」として報告してください。これは「更新するものがない」とは異なります。
• セッション。 決定、修正、ユーザーまたはプロジェクトに関する新しい事実、作成または移動されたファイルはありますか？これにより、メモリと学習ステップに書き込むものがあるかどうかが決まります。読み取りのみのセッションは、コンテキスト保存以外は何も必要としない場合があります。
• Git。 セッションが触れた各リポジトリで git status を実行します。コミットされていない作業はこのスキルがコミットするものではありません。それは計画の「ユーザーとともに残る」行に記載されます。セッションの履歴と git が矛盾する場合（セッションでファイルが変更されたが、ツリーがクリーンなど）、静かに調整するのではなく、矛盾を明記してください。
• 主張された書き込み。 セッションが書き込んだ、作成した、インストールした、または変更したと述べたもの（ファイル、ノート、コミット、設定、インストールされたパッケージ）をリストし、それぞれを読み取り専用で確認します。それが存在し、その内容がセッションが書き込んだものであることを確認します（存在だけではなく、特徴的な行またはサイズ。上書きに失敗すると古いファイルがそのまま残るため）。成功を報告したツールは証拠になりません。内容が異なる場合、更新日時が判断します。セッションの最後の作業より後に変更された場合は、後のセッションがそれを変更したことを意味します（セクション0、stale）。後に変更されていない場合は、書き込みが行われなかったことを意味します。存在すべきファイルが存在しない場合も、後のコミットやノートが削除を記録していない限り、書き込みは行われていません。行われなかった書き込み、またはセッションが中途半端に残した作業（一部の場所でのみインストール、約束して実行しなかったステップ）は、計画の「未完了のまま」行に記載されます（セクション3）。書き込みを主張しなかったセッションはこれをスキップします。
• 進行中の作業 であり、別のスキルが複数のセッションにまたがって行うもの（カタログ、「進行中の作業」）。これは独立したステップではありません。引き継ぎノートとコンテキスト保存に含められます。
• 状態が既に存在する場所。 プロジェクト指示は、ユーザーが情報源として扱うストアを指定している場合があります：保管庫、プロジェクトデータベース、次のアクションを保持するフィールド。書き込みを計画する前に指示を読んでください（ストア自体は、それらに書き込むステップによって読み取られます）。それらはカテゴリ3と5の実行方法を決定します。2つの名前付きストアが同じ事実を保持できる場合（決定ノートとプロジェクトノートなど）、計画は書き込みのターゲットを指定します。指示が解決しない場合は、単一の質問で解決し、決して黙って解決しないでください。

2. 環境によって変わるもの

Claude Code では、カタログの説明に従って各カテゴリを実行します。以下のうち、そう述べているルールのみがそこにも適用されます。セクション0の他の2つのケースでは、次のように調整します。

1 メモリ：確認し、書き込まない。 バックグラウンドパスは各ターン後に永続的なファクトを既にファイリングしています。それが使用した可能性が高いメモリファイルを読み（リストにパスが表示されます）、このセッションの決定がそこにあるかどうかを計画に記載してください。パスは各ターン後に実行されるため、クローズターン自体で決定されたものはまだそこになく、その後ファイリングされます。それは正常であり、ギャップではありません。プラットフォームは、ユーザーの明示的な要求があった場合にのみメモリ書き込みを許可します。そのため、ユーザーが言ったことで欠落しているものがあれば、それを計画に記載し、ユーザーに「保存して」と言わせてください。その文が要求です。プロジェクト内では、書き込みはプロジェクト自身のサブツリーに、メモリ指示で要求された形式で行われます。

1b 引き継ぎノート、2 学習記録：インストールされていない場合はスキップ。 代替はありません。プロジェクト文書、新しいノート、チャットサマリーはそれらにはなりません（1つの場所のルールを参照）。

3 保管庫同期：到達可能性に依存。 デバイスシェルがあり、保管庫フォルダが接続されている場合、同期スキルがインストールされていればそれを実行します。この環境に不足しているものがある場合、スキルはその旨を伝え、その場合は手動で同期を実行します。シェルがなく、コンピュータがリンクされている間のみ、ファイルツールを使って手動で実行します。いずれの場合も、まず保管庫の独自の規則ノートを読み（シェルがない場合はステージング）、提案された各変更を計画に「残すもの」「変更するもの」「削除するもの」として記載し、単一の確認で書き込みをカバーします。フックが書き込むセッションログはここには存在しません。その旨を述べてください。

4 グラフ：未確認（セクション1の通り）。「何もすることはない」ではありません。

5 コンテキスト保存：プロジェクトが指定する場所に書き込む。 これは Claude Code でも同様です。プロジェクト指示が名前を付ける場所は、汎用スナップショットスキルよりも優先され、指示がない場合はインストール済みスナップショットスキルがステップになります。プロジェクト指示が「どこまでやったか」を保持する場所（プロジェクトデータベースのフィールドなど）を1つ指定している場合、その場所がコンテキスト保存です。インストール済みスキルがその場所を所有している場合（日次クローズルーチンなど）、そのスキルがステップです。それがこのセッションで既に実行されている場合はスキップします。そうでなければ、自分でそこに書き込みます。計画には、その場所に提案する正確なテキストが含まれているため、1つの回答でカバーされます。そのルールは、自分で場所に書き込む場合に適用されます。一方、書き込みを所有するスキルは、Claude Code またはその他の環境で、独自のコンテンツを構成します。プロジェクトエントリがセッションが作業した内容をカバーしていない場合は、その旨を述べて提案します。

...

[翻訳のために切り詰められました]