recall について
作業再開前に最近のプロジェクト状況を再構築し、簡潔な要約と次の手順をまとめるワークフロースキルです。チャット履歴と共有記録を調べ、見つかった作業を現在の状態と照合します。
主な機能
- 01期間・トピック・ワークスペースの範囲指定
- 02必要に応じた最近のチャットの並列検索
- 03指定トピックに関する共有記録の調査
- 04関連する PR・ブランチ・チケットの確認
- 05要約・状況・問題・次の手順の整理
活用シーン
- 01プロジェクト作業の中断後に再開
- 02特定機能や不具合の最近の状況を収集
- 03過去の修正と現在の報告を確認してから着手
- 04確認済みの進捗を簡潔に引き継ぐ
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ mdsmithaustin/ pstack --skill recallインストール後、Claude Code で/recallを入力して読み込まれたか確認します。
同梱ファイルagents/openai.yaml
詳細
Recall
作業を開始または再開する前に、ユーザーの最近の作業コンテキストを再構築し、現状と次に行うべきことを簡潔にまとめて返します。
要点を絞り、話題から外れないようにしてください。対象範囲のスレッドに必要なものだけを読み、それ以上は読み込まないでください。
コンテキストは2つの記録にあります。自分のチャット履歴には、自分が行ったことや決定したことが記録されています。共有記録には、同じコードについて別の名前で起きたすべてのこと、つまりユーザーから繰り返し報告される症状、リリース後に差し戻された修正、本番環境でまだ発生しているエラーが記録されています。この2つ目の記録を、ソース管理、課題トラッカー、チャットや課題のチャンネル、長文ドキュメント、エラートラッキングを横断して検索するのが why スキルです。バグが長く尾を引いている機能は、その経緯の大半が共有記録に残っています。自分の書き起こしだけから再構成しないでください。
pstack-harness スキルを使って、このワークスペースの書き起こしストアを特定してください。ファイルベースのストアでは各行が1件のチャットメッセージです。データベースベースのストアも同じ形式にエクスポートされます。
- 分類してから、適切な手順に振り分けます。再開する特定の過去チャットには
session-pickupプレイブックを使いますが、これは該当しません。習慣を永続的なスキルにするには、代わりに automate-me スキルを使います。作業を人が読める形で要約するのは別のタスクです。Recall は、行動を起こす前に最近のチャットを横断して作業コンテキストを読み込みます。ユーザーがすでに完全な状態の要約(パス、ブランチ、変更内容)を提示している場合は、それを使い、情報の掘り起こしは省略します。 - 検索前に対象範囲を確定します。期間(「最近」は実際の期間を指し、既定値は過去7日間)、指定があればトピック、ワークスペース(既定値は現在のワークスペース)を固定します。依頼されていない別のプロジェクトの書き起こしは、決して読みません。対象範囲をユーザーに伝えてください。「すべて」を黙って「直近N件」に置き換えてはいけません。
- チャット履歴を複数の経路で調べます。
how explorerロールのサブエージェントを並列で起動し、それぞれにコーパスの一部を割り当てます。ロールの特定には pstack-harness スキルの Spawn a role セクションを使います。各サブエージェントには、候補をUUID名ではなく実際の更新時刻順(ls -t)に並べること、まずトピックを検索し、一致したチャットとその関連箇所だけを読むこと、現在のチャットと明らかなノイズ(サブエージェント、評価、テストのチャット)を除外することを伝えます。各サブエージェントはチャットごとに1ブロック、同じスキーマで返します。項目は、トピック、ユーザーの目標、決定事項、未解決のスレッド、苦戦した点と修正内容、成果物(PR、チケット、ブランチ)で、それぞれにチャットUUIDを付記します。対象チャットが1〜2件なら、並列処理せず直接検索します。生の書き起こしはサブエージェント側に残し、メインスレッドには調査結果だけを返します。 - トピックで機能、ファイル、サブシステム、領域、バグが指定されている場合は、必ず共有記録も調べます。これは判断の余地がある選択肢ではなく、既定の手順です。「Xに関する自分の作業」も例外ではありません。その際は why スキルの情報源調査担当を使います。ただし、質問を「なぜこの設計なのか」ではなく、「現在の状況はどうか、試したが定着しなかったことは何か、ユーザーから今も報告されていることは何か」に切り替えてください。同スキルの情報源ごとのプレイブックを再利用し、チャット履歴の調査と並行して調査担当を起動します。情報源ごとに担当を1人置くこと、検索結果がないことも調査結果とすること、利用できない MCP はスキップしてその旨を伝えることなど、同スキルの基本方針を引き継ぎます。得られた情報を要約にまとめます。指定された対象がない単なる活動の振り返り(「今週は何をしたか」など)の場合だけ、この手順を省略します。その場合は、自分の履歴と現在の状態だけで回答します。
- 現在の状態と照合します。情報の掘り起こしと共有記録の調査で見つかった PR、ブランチ、チケットを
gitとghで確認します。回答がエージェントの実際の行動(実行したツール、読んだファイル、発生したエラー)に左右される場合は、要約済みのローカルコピーだけでなく、書き起こし全体を読みます。 - 以下の要件に従って要約を作成します。スレッドごとにまとめ、指定されたトピックから外れないようにします。
出力要件
まず要約、次にスレッドの状況、続いて問題点、最後に次のアクションを記載します。詳細はその下に記載するか、省略してください。
- 要約。 最大5項目。この作業の内容と全体的な進捗状況を記載します。
- スレッド。 各スレッドは1行で記載し、次のステータスタグを必ず1つだけ先頭に付けます:[merged #N]、[open PR #N]、[in flight ]、[verified, uncommitted]、[reverted #N]、または[planned, not started]。タグのないスレッドは未完了なので、タグを付けてください。
- 問題点。 繰り返し発生しているものを最大5項目で記載します。ユーザーから繰り返し報告されている症状と、リリース後に取り消された修正があれば含め、次の試みが前回の失敗地点から始められるようにしてください。
- 次のアクション。 最も有用な次の作業を1つ、具体的に記載します。
隣接する機能やチケットは、この作業を妨げていない限り記載しないでください。要約とスレッドの行が画面に収まらなくなった場合は、スレッドを削る前に詳細を削ってください。ブリーフの作成にはunslopスキルを使ってください。チャットで得た知見にはUUIDを、共有記録で得た知見には出典(PR #、チケットID、チャットのパーマリンク、エラートラッカーの課題)を記載し、公開する前に非公開のコンテキストを取り除いてください。
回答: 上記の要件に沿ったブリーフ。