mcpField
B
brief

brief

github.com/davepoonエージェントワークフロー3.7k60 回インストール2 日前に更新
リポジトリ

brief について

brief は、セッション開始時や話題の切り替え時に概要をまとめる Origin のエージェントスキルです。プロジェクトのステータスファイル、関連する記憶、保留中の修正を参照し、ステータスファイルを現在のタスク記録として扱います。

主な機能

  1. 01プロジェクトのステータスファイルを先に読む
  2. 02話題に関連するコンテキスト記憶を取得
  3. 03保留中の記憶の修正を確認
  4. 04現在のタスクと背景情報を区別

活用シーン

  1. 01セッション開始時の状況把握
  2. 02話題変更後の背景確認
  3. 03提案された記憶の修正確認

MCP 対応

Origin MCP サーバーの context と list_pending_revisions ツールを呼び出し、背景情報と確認待ち項目を取得します。

インストール

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

$npx skills add https://github.com/davepoon/buildwithclaude --skill brief

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

詳細

/brief

Origin から厳選されたセッションブリーフを取得します。ソースは次の3つで、この順に確認します。

  1. プロジェクトステータスファイル — /handoff が最後に書き込んだ内容です。現時点で「残っている作業」に関する最も信頼できる情報です。
  2. context MCP — アイデンティティ、好み、トピックに関連する記憶です。背景情報であり、記録台帳ではありません。
  3. list_pending_revisions — デーモンによってフラグが付けられ、レビュー待ちの記憶です。

「次に何をするか」については、ステータスファイルを優先します。記憶はトピックの類似度に基づいて順位付けされるため、古い項目も新しい項目とともに表示されます。一方、ステータスファイルはセッションごとに更新される最新の記録台帳です。

1. まずプロジェクトステータスファイルを読む

プロジェクトルートを検出します。

Bash: cd_repo=$(git -C "$PWD" rev-parse --show-toplevel 2>/dev/null); echo "${cd_repo:-no-git}"
  • 出力がパスの場合 → <project> = ベース名（例：origin）。
  • no-git の場合 → <project> = cwd のベース名。

~/.origin/sessions/_status/<project>.md を読みます。

Bash: cat ~/.origin/sessions/_status/<project>.md

ファイルが存在する場合は、その ## Last session、## Active、## Backlog セクションを一字一句そのまま、ブリーフ出力の先頭に「前回のセッション 時点のステータス」のような見出しを付けて表示します。これが「残っている作業」に関する最も信頼できる情報です。

ファイルがない場合は、そのことについて何も述べません。初めて扱うプロジェクトでは、まだ引き継ぎが行われていません。

2. context を呼び出す

origin MCP サーバーの context ツールを呼び出します。ユーザーがトピック引数を渡した場合は、それをそのまま渡します。そうでない場合は、作業ディレクトリとこれまでの会話から範囲を推測します。ユーザーに質問しないでください。

context(topic="<args or inferred>", space=<inferred from cwd or recent turns>)

範囲の推測ルール：

  • topic：ユーザーが引数を省略した場合は、会話で直近に扱ったトピック（議論中のファイルや機能）を渡します。セッション開始時に新たに一般的なブリーフを作成する場合は、省略します。
  • space：cwd から判断します。~/Repos/origin/... → "origin"。その他のリポジトリ → リポジトリ名。どのリポジトリにも属さない場合 → 省略します。範囲が分かっている場合は必ず渡します。不確かな場合は、後で（PR-C 後に）list_spaces を実行するか、省略します。

使用するタイミング

  • セッション開始時 — 他の Origin ツールを使う前に呼び出します。
  • セッション中に大きくトピックが変わったとき。
  • ユーザーが「状況を教えて」「X の背景は？」「Y について思い出させて」と言ったとき。
  • セッション中の確認で、前提を確かめたいとき。

使用しないタイミング

  • 特定の事実を調べる場合 → より対象を絞った /recall を使います。
  • 新しい記憶を保存する場合 → /capture を使います。
  • セッション終了時 → /handoff を使います。

結果の使い方

ステータスファイルは最新の記録台帳（次に行う作業）として、context の記憶は背景情報（ユーザーの考え方）として扱います。ステータスファイルで完了とされている項目を、記憶がまだ保留中として示している場合は、ステータスファイルを信頼してください。記憶は自動的に新しい情報へ置き換わりません。食い違いに気づいた場合は、古い記憶をそのまま繰り返すのではなく、文中で指摘してください。

ユーザーの考え方を理解しましょう。ユーザーの好み、訂正、過去の決定からは、すでに知っていることだけでなく、どのような支援を望んでいるかが分かります。情報を調べるだけでなく、それに応じて対応を調整してください。

3. 保留中の改訂の確認

コンテキストを読み込んだ後、次を呼び出します。

list_pending_revisions(limit=10)

結果が空の場合は、何も言わないでください。「保留中の改訂は 0 件です」や「すべて問題ありません」といった文も表示しないでください。ブリーフはすでに十分雑然としています。

MCP 呼び出しでエラーが発生した場合は、警告を 1 行記録して続行します。ブリーフをエラー終了させないでください。

結果が空でない場合は、ブリーフの末尾（コンテキストの要約の後、ユーザーに返す前）にブロックを表示します。デーモンは行をすでに last_modified DESC で並べ替えているため、先頭の 3 件だけを取り出します。

各 PendingRevisionItem には、target_source_id、revision_source_id、revision_content、source_agent、last_modified が含まれます。元のメモリの内容はこのレスポンスには含まれません。このブロックには、提案された改訂テキストと対象メモリ ID が表示されます。ユーザーが判断する前に元の内容を確認したい場合は、先に /recall <target_source_id> を実行できます。

Pending revisions (<N> total, top 3 shown):

1. target: mem_abc123  (proposed by <source_agent or "daemon">)
   revision: "Origin uses Turso libSQL fork (libSQL-server) for vectors..."
   Action: accept (replace original) | dismiss (drop revision) | skip

2. ...

インラインの承認／却下の動詞は、次のように対応付けます。

  • accept: accept_revision(target_source_id="<id>")
  • dismiss: dismiss_revision(target_source_id="<id>")
  • skip: 呼び出しを行わない。改訂は次回の /brief まで保留のままになります

<N> > 3 の場合は、ブロックの末尾に次の 1 行を追加します。

Run `/review revisions` to walk the rest.

何も自動で処理しないでください。各項目についてユーザーが選択します。

注：このブロックには、今回のセッションのものだけでなく、保留中のすべての改訂が表示されます。矛盾が指摘された時期にかかわらず、現在も使用している可能性のあるメモリに関する改訂だからです。

コメント

Markdown 対応