recall

リコール

太字またはバッククォートで示されたスキル名、あるいは /<name> として実行されるスキルは、このスキルのディレクトリの隣にある ../<name>/SKILL.md ファイルです。接頭辞なしで指定された原則名は、../principle-<name>/SKILL.md ファイルです。そのファイルを読み、指示に従ってください。pstack スキルの大半はユーザー専用のため、スキルツールでは読み込めません。すべての delegate_task 呼び出しには、../poteto-mode/SKILL.md の Subagents セクションにある既定値が適用されます。

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

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

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

このプロジェクトのチャット履歴は T3 スレッドです。t3_thread_list は新しい順に一覧表示します（includeSubagents: true を指定すると委任先の子スレッドも含まれます）。t3_thread_search はテキストで検索し、t3_thread_read はスレッドを時系列で読み取ります（view: "activity" を指定するとツール呼び出しも含まれます）。

1. まず分類し、その後に振り分けます。再開する特定の過去のチャットがある場合は、こちらではなく session-pickup プレイブックを使います。習慣を持続的に使えるスキルにする場合は、automate-me を使います。人が読める作業の要約は別のタスクです。Recall は行動を始める前に、最近のチャットから作業コンテキストを読み込みます。ユーザーが状態をまとめた情報（パス、ブランチ、変更内容）をすでにすべて提示している場合は、それを使い、情報の掘り起こしは省略します。
2. 検索する前に範囲を確定します。期間（「最近」は明確な範囲を指し、デフォルトは過去 7 日間です）、指定があればトピック、ワークスペース（デフォルトはアクティブなワークスペースです）を定めます。依頼されていない限り、別のプロジェクトのトランスクリプトは決して読みません。範囲をユーザーに伝えます。「すべて」を黙って「最近の N 件」に置き換えてはいけません。
3. チャット履歴を並行して調べます。このプロジェクトの t3_thread_list を使い、期間を超えるまでページを取得します。現在のチャットと明らかなノイズ（サブエージェント、評価、テストのチャット）を除外し、残ったスレッド ID を t3_thread_list の順序（スレッド ID ではなく、実際の最終アクティビティ順）を保ったまま分割します。t3_thread_search の検索範囲には限りがあるため、ヒットは手がかりであり、全データではありません。orchestrator_capabilities にある高速で低コストのモデルを使って、スライスごとに delegate_task の子タスクを並行して起動します。それぞれの title に担当スライスを記載し、依頼文に対象スレッド ID を明記します。各依頼文には「読み取り専用：調査のみ、書き込みなし、git コマンドなし」と「委任しない」を含め、サブエージェントに次の作業を指示します。担当する各 ID について t3_thread_read を実行し、トピックに関するスレッドのみを残し、さらにその中から関連部分のみを抽出します。hasMore が false になるまで nextPosition をたどり、途中で切れた項目は itemId と textOffset を使って復元します。各チャットについて、同じスキーマで結果を返します。スレッド ID を引用しながら、トピック、ユーザーの目標、決定事項、未解決の論点、苦戦した点と修正、成果物（PR、チケット、ブランチ）をそれぞれ 1 ブロックにまとめます。対象チャットが 1、2 件の場合は、並列処理を省略して直接検索します。生のトランスクリプトはサブエージェント内に留めます。メインスレッドには調査結果だけを返します。サブエージェントの推論レベルと高速・標準の速度は、poteto-mode スキルの Subagents セクションに従って、作業に合わせて選択します。
4. トピックに機能、ファイル、サブシステム、領域、またはバグが含まれる場合は、共有記録も必ず調べます。これはデフォルトの手順であり、判断に委ねるものではありません。「X に関する自分の作業」であっても例外にはなりません。why スキルの情報源調査担当者に調査を依頼します。ただし、質問は「なぜこのように実装されたのか」から「現在の状態はどうか、これまでに試して定着しなかったことは何か、ユーザーは今も何を報告しているか」へと調整します。情報源ごとのプレイブックを再利用し、チャット履歴の調査と並行して担当者を動かします。また、同スキルの基本方針に従い、情報源ごとに担当者を 1 人割り当て、結果が見つからなかったことも調査結果として扱い、利用できない MCP はスキップしてその旨を伝えます。調査結果を概要に反映します。この手順を省略できるのは、対象が指定されていない純粋な活動履歴の振り返り（「今週何をしたか」など）のみです。この場合は、自分の履歴と現在の状態だけで回答します。
5. 現在の状態を照合します。調査と共有記録の確認で見つかった PR、ブランチ、チケットを git と gh で確認します。エージェントが実際に何をしたか（実行したツール、読んだファイル、発生したエラー）が回答の鍵となる場合は、要約だけでなく t3_thread_read でスレッド全体を読みます（view: "activity" を指定し、hasMore が false になるまで nextPosition をたどり、途中で切れた項目は itemId と textOffset を使って復元します）。
6. 以下の要件に従って概要を作成します。スレッドごとにまとめ、指定されたトピックに絞ります。

出力規約

要約、スレッドの状況、問題点、次のアクションの順に記載します。詳細はその下に記載するか、省略します。

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

隣接する機能やチケットは、この作業を妨げていない限り含めません。要約とスレッドの行が画面に収まらなくなった場合は、スレッドを削る前に詳細を削ってください。unslop スキルを使ってブリーフを作成し、チャットで得た知見にはスレッド ID、共有記録で得た知見には出典（PR 番号、チケット ID、チャットのパーマリンク、エラートラッカーの課題）を明記してください。また、公開する前に個人情報や機密情報を削除してください。

返信： 上記の規約に沿ったブリーフ。