recall

Recall

作業を開始または再開する前に、ユーザーの最近の作業コンテキストを再構築し、現在の状況と次に行うことを簡潔にまとめて渡します。

要点を絞り、話題から外れないようにします。対象範囲のスレッドに必要なものだけを読み、そこで止めます。

コンテキストは2つの記録にあります。自分のチャット履歴には、あなたが行ったことや決めたことが記録されています。共有記録には、同じコードについて別の名義で起きたことがすべて記録されています。ユーザーから繰り返し報告される症状、リリース後に取り消された修正、本番環境で今も発生しているエラーなどです。この2つ目の記録を検索するのが why スキルで、ソース管理、課題トラッカー、チャットや課題のチャンネル、長文ドキュメント、エラー追跡を横断して検索します。長くバグが続いている機能は、その経緯の大半がそこに残っているため、自分のトランスクリプトだけから再構成しないでください。

トランスクリプトは ~/.cursor/projects/<slug>/agent-transcripts/<uuid>/<uuid>.jsonl にあります。<slug> は先頭のスラッシュを取り除き、各「/」を「-」に置き換えたワークスペースのパスです（例：/Users/you/proj は Users-you-proj になります）。各行は1つのチャットメッセージです。

1. 分類してから、適切な方法に振り分けます。再開する特定の過去チャットを1つ選ぶなら、それは session-pickup プレイブックであり、このスキルではありません。習慣を永続的なスキルにするのは automate-me です。作業内容を人間が読める形で要約するのは別のタスクです。Recall は、行動を起こす前に最近の複数のチャットから作業コンテキストを読み込みます。ユーザーがすでに完全な状況説明（パス、ブランチ、変更内容）を提示している場合は、それを使い、情報の掘り起こしは省略します。
2. 検索前に対象範囲を固定します。期間（「最近」は実際の期間を指し、既定では過去7日間）、指定されていればトピック、ワークスペース（既定ではアクティブなもの）を明確にします。求められていない限り、別のプロジェクトのトランスクリプトは決して読みません。対象範囲をユーザーに伝えます。「すべて」を黙って「最近のN件」に置き換えてはいけません。
3. 自分のチャット履歴を分担して調べます。高速で低コストなモデルを使う並列サブエージェントを起動し、それぞれにコーパスの一部を担当させます。各サブエージェントには、候補をUUID名ではなく実際の更新日時（ls -t）で並べること、まずトピックを検索し、一致したチャットとその関連箇所だけを読むこと、現在のチャットと明らかなノイズ（サブエージェント、評価、テストのチャット）を除外することを伝えます。各サブエージェントはチャットごとに1ブロックを返し、すべて同じ項目を含めます。すなわち、トピック、ユーザーの目的、決定事項、未解決の論点、問題点と修正、成果物（PR、チケット、ブランチ）を記載し、各項目にはチャットUUIDを付けます。該当するチャットが1〜2件なら、分担せずに直接検索します。生のトランスクリプトはサブエージェント側に留めます。メインスレッドには調査結果だけを返します。推論レベルと高速／標準の速度は、poteto-mode スキルの「Subagents」セクションに従って、各サブエージェントの作業に合わせて選びます。
4. トピックで機能、ファイル、サブシステム、領域、またはバグが指定されている場合は、共有記録も必ず調べます。これは既定の手順であり、判断に委ねられるものではありません。「Xに関する自分の作業」であっても、例外にはなりません。調査は why スキルの情報源調査担当に任せます。ただし、質問は「なぜこのように構築されたか」ではなく、「現在の状況はどうか、何が試されて定着しなかったか、ユーザーから今も何が報告されているか」に焦点を当てます。情報源ごとのプレイブックを再利用し、チャット履歴の調査と並行して調査担当を実行します。その進め方も引き継ぎます。情報源ごとに担当を1人割り当て、結果がない場合も調査結果として扱い、利用できない MCP はスキップしてその旨を伝えます。得られた情報を概要に反映します。トピックが指定されていない純粋な活動履歴の振り返り（「今週何をしたか」など）の場合に限り、この手順を省略できます。この場合は、自分の履歴と現在の状態だけで回答します。
5. 現在の状態と照合します。情報の掘り起こしや共有記録の調査で見つかったPR、ブランチ、チケットを git と gh で確認します。エージェントが実際に何をしたか（実行したツール、読んだファイル、遭遇したエラー）が回答の根拠となる場合は、抜粋されたローカルコピーだけでなく、トランスクリプト全体を読みます。
6. 以下の仕様に従って概要を作成します。スレッドごとにまとめ、指定されたトピックから外れないようにします。

出力の形式

最初に概要、次にスレッドの状況、その次に問題、最後に次のアクションを記載してください。詳細は下に記載するか、省略してください。

• 概要。 最大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、チャットのパーマリンク、エラートラッカーの課題）を引用し、公開前に非公開情報をサニタイズしてください。

**返信：**上記の形式に従ったブリーフ。