/clear で作業を失わないで — session-handoff の紹介

長いデバッグセッションを終えて /clear を実行し、その1週間後になって、チームがどの3つのデータベースの選択肢を却下したのか思い出したいと思ったことがあるなら、これはあなた向けです。

問題は小さいですが、コストは大きいものです。実際のプロジェクトで AI エージェントと作業すると、ほかには存在しない知識の層が生まれます。なぜ特定のライブラリが見送られたのか。どのステージング環境が壊れているのか。ユーザーが「the gate」で本当に意味していたのは何か。コードにはありません。git にもありません。会話の中にあります。そして、その会話は消されようとしています。

救出テスト

session-handoff は、クリアする前に実行される小さな Agent Skill です。セッション内の事実をスキャンし、1つの決定的な質問を適用します。

「リポジトリを読み直せば、これを再現できますか？」

はいなら、捨ててください — コードこそが唯一の正しい情報源です。いいえなら、保存する価値があるかもしれません。このたった1つのヒューリスティックで、誤って保存されるものの約80%を取り除き、長期メモリファイルがノイズだらけになるのを防ぎます。

実際の動作

流れは7ステップですが、体験としては2つです。まず 「checkpoint before clearing」 のようなトリガーを入力し、保存される内容を確認して承認します。その後、このスキルが構造化された markdown エントリを書き込みます。役割と環境には user、作業ルールには feedback、目標と判断には project、外部システムへの参照には reference を使い、さらに1行の索引ファイルを更新して、次回以降のセッションで低コストに読み込めるようにします。

実用性を本当に高めている技術的なポイントが2つあります。

• 日付の正規化。 「Thursday」 は抽出時に 2026-05-21 に変換されるので、3か月後でもそのエントリの意味が通ります。
• Why / How 構造。 すべての feedback や project のエントリには、理由（多くは過去の出来事）と そのルールが適用される時 が含まれます。これにより、将来の自分がメモを盲目的に従うのではなく、境界ケースを判断できるようになります。

こんな人に必要です

長期にわたる移行作業、複数の関係者が関わるロールアウト、あるいは口頭での合意が、その会話を生んだ瞬間より長く生き残るような仕事に関わっているなら、これです。プラットフォームのリード、SRE、作業を引き継ぐ契約エンジニア。賢いからではありません。代わりにあるのは、すでに知っていたことを3週間遅れで、しかもひどい形で再構築することだからです。

リポジトリは公開されており、このスキルは1回で読めるほど小さいです。

👉 github.com/andreab67/agent-skills/blob/main/session-handoff/SKILL.md