recall

Recall

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

簡潔に、話題に沿ってまとめてください。対象範囲のスレッドに必要なものだけを読み、それ以上は読み込まないでください。

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

トランスクリプトは、ハーネスが保存している場所にあります。各ファイルは JSONL 形式です。現在のワークスペースで使われているハーネスのディレクトリを探してください。どのハーネスを使っているか分からない場合は、このワークスペースに次のいずれが存在するか確認してください。

• Cursor： ~/.cursor/projects/<slug>/agent-transcripts/<uuid>/<uuid>.jsonl。<slug> はワークスペースのパスから先頭のスラッシュを取り除き、各「/」を「-」に置き換えたものです（/Users/you/proj は Users-you-proj になります）。
• Claude Code： ~/.claude/projects/<slug>/<session-id>.jsonl。<slug> は、英字または数字以外のすべての文字を「-」に置き換えたワークスペースのパスです（/Users/you/proj は -Users-you-proj になります）。
• Pi： ~/.pi/agent/sessions/--<slug>--/<timestamp>_<id>.jsonl。<slug> はワークスペースのパスから先頭のスラッシュを取り除き、各「/」を「-」に置き換えたものです（--Users-you-proj--）。
• Codex： ~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl。ワークスペースごとにグループ化されていません。1行目の payload.cwd がワークスペースのパスと一致するファイルだけを対象にしてください。
• OpenCode： ~/.local/share/opencode/storage/。セッションは session/<project-id>/ の下に JSON ファイルとしてあり、メッセージは message/ と part/ に保存されています。

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

出力形式

最初にカプセル、次にスレッドの状況、その後に問題点、最後に次のアクションを記載します。詳細は下に回すか、省略します。

• カプセル。 最大 5 項目。この作業の内容と全体的な状況を記載します。
• スレッド。 各スレッドを 1 行で記載し、必ず次のステータスタグを 1 つだけ先頭に付けます：[merged #N]、[open PR #N]、[in flight ]、[verified, uncommitted]、[reverted #N]、[planned, not started]。タグのないスレッドは未完了なので、タグを付けます。
• 問題点。 繰り返し発生しているものを最大 5 件記載します。ユーザーから繰り返し報告されている症状と、実装後に差し戻された修正があれば含め、次の試みが前回の失敗地点から始められるようにします。
• 次のアクション。 最も有用な次のアクションを 1 つ、具体的に記載します。

隣接する機能やチケットは、対象をブロックしている場合を除き、含めません。カプセルとスレッドの行が画面に収まらない場合は、スレッドを削る前に詳細を削ります。unslop スキルを使って概要を書き、チャットの調査結果は UUID、共有記録の調査結果は情報源（PR #、チケット ID、チャットへのパーマリンク、エラートラッカーの課題）を引用します。また、公開する前にプライベートなコンテキストをサニタイズします。

返信： 上記の形式に従った概要。