prepare-clear: 文脈を捨てる前に、消えて困るものを外へ出す

既定は /clear (要約を残さない)。理由は 2 つ。

• 要約は劣化する。しかも劣化した写しが、そのままコンテキストを占める
• 圧縮そのものが会話全文を読むコストを払う。長い会話ほど高くつくので、 圧縮したくなった時点がいちばん高い

残件を TODO.md に書き、調査の記録を notes/ に書けば、次のセッションは 必要なファイルだけ読み直せばよい。それは全文要約より安い。

/compact を選ぶのは例外で、手順 2 の後に「ファイルへ書けない途中状態」が 残ったときだけ。例: 仮説が半分だけ検証済みで、まだ記録へ書ける形になっていない。 実機の観測値が生ログのままで、置き場所が決まっていない。

/clear も /compact もユーザーのコマンドなので、こちらからは実行できない。 文言を提示して、ユーザーに打ってもらう。

手順

1. 会話にしか無い情報を洗い出す

いま進行中の作業について、次を思い出す。「仕切り直した後の自分が知らないと 困ること」だけ。

• 進行中タスクの位置 (どこまで終わり、次は何か)
• 決定した方針と、却下した案とその理由 (再提案を防ぐ)
• 実機・実環境の値 (接続先、ポート、デバイス ID)
• 未コミット/未 push の状態と、それに関する制約
• 今日訂正した内容 (同じ間違いを繰り返さないため)
• ユーザーから受けた指示のうち、まだ効いているもの

2. ファイルへ出せるものを出す

**出せるものは全部出す。**引き継ぎは短いほど劣化しない。

行き先は下表を目安にするが、そのプロジェクトが既に使っている場所が優先。 CLAUDE.md にディレクトリ規約があればそれに従い、無ければ既存ファイルの 置き方に合わせる。

残件は 1 行ずつ TODO へ書く。**書いた項目は引き継ぎから外す。**二重に持たない。

置き場所が無い種類の情報なら、無理に新しいディレクトリを作らない (1 項目のために規約を増やすほうが後で害になる)。

実データ (実パス・実機ログ・ホスト名) はプロジェクトの規約に従う。 公開 repo に書かない取り決めがあるなら、引き継ぎの文言にも書かない (文言は会話に残り、コミットメッセージへ紛れ込みうる)。

scratchpad に後で要る物が置かれていないかを確認する。置かれているなら:

• 恒久的に要る物 (バックアップの bundle、退避したデータ) は、恒久的な場所へ 移すことを提案する。scratchpad はセッション単位なので消える前提で扱う
• 移さない判断なら、絶対パスを引き継ぎに書く。次のセッションは自力でその ディレクトリを見つけられない

3. 残ったかどうかで行き先を決める

手順 2 の後にファイルへ書けなかった項目が残っているかを数える。

• 残っていない (通常) → /clear を提案し、最初の発言を組み立てる (下記 4)
• 残った (例外) → /compact の引数を組み立てる (下記 5)。項目ごとに 「なぜファイルに書けなかったか」を書く。書ける形になったら、次のセッションで ファイルへ出して引き継ぎから落とす

4. 最初の発言を組み立てる (/clear の場合)

4 つの節で書く。読む順序を指定するのが要点 — 仕切り直した後には要約が 無いので、どこから読めば全体が掴めるかを教える必要がある。

1. 現在地 — 1〜2 文。何が終わって、何が未解決か。数字を入れる (コミット数、テストの状態、repo がクリーンかどうか)
2. まず読むファイル (順序付き) — 各行に「何が書いてあるか」を添える。 最初の 1 つは全体の位置が分かるもの (TODO.md の現在地など) にする。 ファイル名だけ並べても、何を期待して読むのかが分からない
3. 次にやること — 具体的な次の一手。人間の手の要る部分があれば明記する (でないと次のセッションが勝手に進めようとする)。守ってほしい規約があれば ここで名指しする
4. 環境の事実 — ファイルに書けない/書くべきでないもの:
   • テストやビルドの起動方法で、既定と違うもの (環境変数、DISPLAY など)
   • PATH や導入状態のようなこのマシン固有の事実 (公開 repo に書くと他環境で嘘になる)
   • scratchpad の絶対パス (残した物があるなら)

memory は自動で索引が読まれるが、索引は 1 行の手掛かりしか持たない。 今の作業で効くものは「本文まで読んでほしい」と名前で指定する。

5. 引数を組み立てる (/compact の場合)

形式:

• 冒頭に現在地を 1 文 (何のフェーズの何が終わって、次が何か)
• 次に参照先を 1 文 (「詳細は X と Y にあるのでそちらを読めばよい」)
• そのあとに会話にしか無い項目を番号付きで列挙

長さの目安は 3〜6 行。ファイルを指せるものを引数に書き写さない。

6. 提示のしかた

どちらの経路でも、コピーしやすいようコードブロックに入れる。 あわせて次の 2 つを短く書く:

• 残す理由 — 項目ごとに「なぜファイルに書けなかったか」
• 残さないもの — ファイル済みなので落とす、と明示する。 ユーザーが「あれは入れなくていいのか」と確認する手間を消す

7. 仕切り直した後

/clear の場合、最初の仕事は指定されたファイルを読むこと。読む前に作業を 始めない。読んだ結果と最初の発言が食い違っていたら、ファイルを正とし、 食い違いを報告する (発言は書いた時点の記憶で、ファイルの方が新しい)。

/compact の場合は、引数に書いた次のタスクから再開する。前置きは要らない。

/clear と新しいセッションの違い

成果物は同じなので、どちらでも同じ最初の発言が使える。選び分けの基準は 1 つ: settings.json や MCP の定義を変えたなら、端末を開き直す方が確実に読み直される。

scratchpad のパスは新しいセッションでは変わる。/clear で変わるかは環境依存な ので、変わる前提で手順 2 のとおり恒久的な場所へ移しておく。

やらないこと

• 会話全体を要約しようとしない。要るのは「どこを読むか」と「次に何をするか」
• ファイルに書ける情報を引き継ぎだけに置かない (後から検証できなくなる)
• 「念のため」で /compact の引数を長くしない。長い引数は要約の中で薄まる
• scratchpad のパスを書かずに「バックアップは scratchpad にある」と書かない
• ユーザーの代わりに /clear や /compact を実行しようとしない (できない)
• 破棄した作業の経緯を引き継ぎに詰め込まない。破棄したこと自体が重要なら ファイルへ書く (再提案を防ぐため)。引き継ぎはそのファイルを指すだけでよい