mcpField
R
recall

recall

github.com/michael-denyer生産性3.6k872 回インストール今日更新
リポジトリ

recall について

recallは、作業の開始時や再開時に直近の状況を再構成するエージェントスキルです。複数の会話をまたいでプロジェクトを進める場合に、範囲を絞った会話検索、共有記録の調査、最新状態の確認を行い、進捗と次の行動を簡潔にまとめます。

主な機能

  1. 01ワークスペース、話題、期間を限定
  2. 02最近の会話を並行して検索
  3. 03共有記録から現在の状況と過去の試行を確認
  4. 04PR、ブランチ、チケットの最新状態を検証
  5. 05進捗と次の行動を定型形式で整理

活用シーン

  1. 01過去の会話からプロジェクト作業を再開
  2. 02機能やバグの現在の状況を把握
  3. 03着手前に関連する議論、問題、次の行動を整理

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/michael-denyer/pstack-claude --skill recall

インストール後、Claude Code で/recallを入力して読み込まれたか確認します。

詳細

Recall(振り返り)

GitHub Copilot では、このスキルに従う前に、スキルごとの注記も含めてプラットフォーム対応表を確認してください。

Muse では、このスキルに従う前に、スキルごとの注記も含めてプラットフォーム対応表を確認してください。

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

簡潔に、話題から外れないようにしてください。対象範囲のスレッドに必要なものだけを読み、そこで止めてください。

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

トランスクリプトは ${CLAUDE_CONFIG_DIR:-$HOME/.claude}/projects/<encoded-cwd>/<uuid>.jsonl にあります。各行はチャットメッセージ1件です。node <plugin>/skills/reflect/scripts/claude-project-dir.mjs を実行すると、<encoded-cwd> を手作業で組み立てずに、このセッションのディレクトリを表示できます。Claude Code は、ASCII の英字または数字以外の各文字を「-」に置き換えます(そのため、/Users/you/my_app.web は -Users-you-my-app-web になります)。名前が200文字を超えるとハッシュを付けて短縮し、CLAUDE_CONFIG_DIR が設定されている場合は、代わりに CLAUDE_CODE_PROJECT_DIR_NAME を使用します。

  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 はスキップしてその旨を伝えます。得られた情報を概要に反映します。また、未記録と報告する前に、プロジェクトの恒常的なルールで指定されている、未処理または記録済みの項目があるすべての場所(メモリディレクトリ、決定ログ、.planning/ ツリー、プロジェクトの CLAUDE.md ポインターなど)も調査します。プロジェクトのルールで指定された場所を調べていない場合、検索は完了していません。対象が指定されていない純粋な活動の振り返り(「今週何をしたか」など)で、自身の履歴と現在の状態だけで答えが得られる場合に限り、この手順を省略します。
  5. 人間の判断に関する主張には、人間の決定に関する主張を適用します。厳密な範囲が重要な場合は、出典と、帰属先が明確な原文の表現を保ち、エージェントによる解釈とは分けて記載します。コピーされた要約は、1 つの証拠の連鎖として扱います。
  6. 現在の状態と照合して検証します。調査で見つかった PR、ブランチ、チケットを git と gh で確認します。エージェントが実際に行ったこと(実行したツール、読んだファイル、遭遇したエラー)が回答の要点となる場合は、ローカルに保存された短縮版だけでなく、会話記録の全体を読みます。
  7. 以下の要件に従って概要を作成します。スレッドごとにまとめ、指定されたトピックに絞ります。

出力の形式

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

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

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

コメント