recall について
Recallは、プロジェクト作業を再開するエージェント向けのコンテキスト復元スキルです。最近のチャットや指定トピックの共有記録を調べ、現状を確認して簡潔な状況報告を作成します。
主な機能
- 01最近のチャット履歴の検索
- 02指定トピックの共有記録の調査
- 03チャットと情報源の並行調査
- 04gitとghによる作業状況の確認
- 05範囲を絞った状況要約の作成
活用シーン
- 01中断後のプロジェクト作業の再開
- 02機能や不具合の現状把握
- 03過去の修正と未解決報告の確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ ericlitman/ open-pstack --skill recallインストール後、Claude Code で/recallを入力して読み込まれたか確認します。
詳細
Recall
作業を開始または再開する前に、ユーザーの直近の作業コンテキストを再構築し、現在の状況と次にすべきことを簡潔にまとめて返します。
要点を絞り、話題から逸れないようにします。対象範囲のスレッドに必要なものだけを読み、そこで止めます。
コンテキストは2つの記録にあります。自分のチャット履歴には、自分が行ったことや決定したことが残っています。共有記録には、同じコードをめぐって別の名前で起きたすべてのことが残っています。ユーザーから繰り返し報告されている症状、リリース後に取り消された修正、本番環境でまだ発生しているエラーなどです。この2つ目の記録を検索するのが why スキルです。ソース管理、課題トラッカー、チャットや課題のチャンネル、長文ドキュメント、エラー追跡を横断して検索します。不具合が長く続いている機能の経緯は、その大半が共有記録に残っているため、トランスクリプトだけから再構築しないでください。
トランスクリプトは ~/.claude/projects/<encoded-cwd>/<uuid>.jsonl にあります。<encoded-cwd> は、先頭のスラッシュを除き、各「/」を「-」に置き換えたワークスペースのパスです(そのため /Users/you/proj は -Users-you-proj になります)。各行は1件のチャットメッセージです。
- 分類してから、適切な手順に進みます。特定の過去チャットを再開する場合は、この手順ではなく
session-pickupプレイブックを使います。習慣を持続的に使えるスキルにする場合はautomate-meを使います。作業内容を人が読める形で要約するのは、別のタスクです。Recall は、行動を起こす前に最近のチャット全体から作業コンテキストを読み込みます。ユーザーがすでに状態をまとめた情報(パス、ブランチ、変更内容)を提示している場合は、それを使い、情報の掘り起こしは省略します。 - 検索前に対象範囲を確定します。期間(「最近」は具体的な期間で、既定では過去7日間)、指定された場合は話題、ワークスペース(既定では現在のワークスペース)を決めます。別のプロジェクトのトランスクリプトは、求められない限り読まないでください。対象範囲をユーザーに伝えます。「すべて」を黙って「直近N件」に置き換えてはいけません。
- チャット履歴を横断的に調べます。高速で低コストのモデルを使い、コーパスを分担する複数のサブエージェントを並行して起動します。各サブエージェントには、候補をUUID名ではなく実際の更新日時順に(
ls -tで)並べること、まず話題を検索し、その後、一致したチャットの関連部分だけを読むこと、現在のチャットと明らかなノイズ(サブエージェント、評価、テストのチャット)を除外することを指示します。各サブエージェントは、チャットごとに次の共通スキーマで1ブロックを返します。話題、ユーザーの目的、決定事項、未解決事項、課題と修正内容、成果物(PR、チケット、ブランチ)。それぞれの情報にはチャットのUUIDを記載します。対象が1~2件のチャットだけなら、サブエージェントへの分担を行わず、直接検索します。元のトランスクリプトはサブエージェント側に残し、メインスレッドには調査結果だけを返します。サブエージェントの作業量は poteto-mode スキルの「サブエージェント」セクションに従って決めます。 - 話題に機能、ファイル、サブシステム、領域、バグが含まれる場合は、必ず共有記録も調べます。これは任意の判断ではなく、既定の手順です。「Xに関する自分の作業」も例外ではありません。why スキルの情報源調査担当に依頼しますが、質問は「なぜこのように作られたか」ではなく、「現在の状態はどうか、試したが定着しなかったことは何か、ユーザーからまだどのような報告があるか」に切り替えます。各情報源の既存プレイブックを再利用し、チャット履歴の調査と並行して調査担当を動かします。各情報源につき担当は1人とし、結果がなかった場合も調査結果として扱います。利用できない MCP はスキップし、その旨を伝えます。調査結果をブリーフに反映します。対象が指定されていない純粋な活動の振り返り(「今週は何をしたか」など)に限り、この手順を省略できます。この場合、自分の履歴と現在の状態だけで答えます。
- 現在の状態と照合します。履歴の調査と共有記録の調査で見つかった PR、ブランチ、チケットを、
gitとghで確認します。エージェントが実際に行ったこと(実行したツール、読んだファイル、発生したエラー)が回答の根拠となる場合は、切り詰められたローカルコピーだけでなく、トランスクリプト全体を読みます。 - 以下の要件に従ってブリーフを作成します。スレッドごとにまとめ、指定された話題に集中します。
出力の形式
最初に概要、次にスレッドの状況、その次に問題、最後に次のアクションを記載してください。詳細は下に記載するか、省略してください。
- 概要。 最大5項目。この作業の内容と、全体としての現在の状況を記載します。
- スレッド。 1行につき1件とし、行頭に次のステータスタグを1つだけ付けます:
[merged #N]、[open PR #N]、[in flight <branch>]、[verified, uncommitted]、[reverted #N]、または[planned, not started]。タグのないスレッドは未完了です。タグを付けてください。 - 問題。 最大5件。繰り返し発生している問題を記載します。ユーザーから繰り返し報告されている症状と、公開後に取り消された修正があれば含め、次の試みが前回の失敗地点から始められるようにします。
- 次のアクション。 最も有用な次のアクションを1つ、具体的に記載します。
隣接する機能やチケットは、この作業を妨げていない限り記載しないでください。概要とスレッドの行が画面に収まらなくなったら、スレッドを削る前に詳細を削ってください。unslopスキルを使ってブリーフを作成し、チャットの調査結果はUUID、共有記録の調査結果はその出典(PR #、チケットID、チャットのパーマリンク、エラートラッカーの課題)を引用し、公開前に非公開情報をサニタイズしてください。
**返信:**上記の形式に従ったブリーフ。