priscilarwagner/meeting-digest

Meeting Digest

ツール: ステップコールロール操作 (pm.*, email.*, calendar.*, docs.*, files.*, comms.*)。それぞれを Context/agent-config.md → ツールスタック と、それが指定するアダプター (.claude/adapters/README.md) を通じて解決します。ロールが none に設定されている場合 → そのステップをスキップします。

対象日のすべてのミーティングを取得し、それぞれのノートまたはトランスクリプトを見つけ、構造化されたダイジェストを生成してローカルに保存します。対象日はデフォルトで今日になります。「yesterday」が渡された場合は前日を処理します。

設定

最初に Context/agent-config.md を読んでください。以下を使用します:

• timezone — すべての日付計算に使用
• base_directory — ファイルパスの構築と冪等性チェックに使用
• calendar_exclusions — スキップするミーティングタイトルのパターンリスト
• ツールスタック → ミーティングノート — ミーティングコンテンツの取得元

ステップ4でプロジェクト名とマイルストーン名を認識するために、目標ファイル (agent-config 内のパス) を読んでください。

---

手順

すべてのステップを順番に実行してください。明示的に一時停止するよう指示がない限り、ステップ間で確認を求めないでください。

---

ステップ 1 — 対象日の未ダイジェストのミーティングをすべて取得

フェーズ A — カレンダー: ミーティングリストを取得

1. ユーザーのタイムゾーンで対象日を計算します。デフォルト = 今日。ユーザーが「yesterday」を渡した場合は、1日を引きます。

2. calendar.events(対象日の開始, 対象日の終了) をユーザーのタイムゾーンで実行します。

3. 実際のミーティングのみにフィルタリングします。 以下の条件に該当するイベントは削除します:

   • summary が calendar_exclusions のパターンに一致する
   • 集中時間や作業場所ブロックである
   • attendees リストが空、またはユーザーのみを含む (個人ブロック)

4. 時系列順に並べ替えます (最も古いものを最初)。これが処理するミーティングの順序付きリストです。

フェーズ B — 冪等性チェック

各ミーティングについて:

1. 期待されるノートファイル名を導き出します: YYYY-MM-DD - [ミーティング名].md。カレンダーイベントの summary を使用します。名前をサニタイズします: /, \, :, | を - に置き換え、絵文字を削除し、連続するスペースを1つにまとめます。
2. [base_directory]/Context/Meeting Notes/ にその名前のファイルが既に存在するか確認します。
3. 存在し、既に ## Summary セクションがある場合 → このミーティングをスキップします。出力: "[ミーティング名] のノートは既に存在します — スキップします。"
4. 生のノートとして存在する場合 (## Summary なし) → その内容をソースとして使用し、処理を続行します。
5. 存在しない場合 → フェーズ C に進みます。

フェーズ C — ミーティングコンテンツを見つける

以下の順序でソースを確認し、コンテンツがある最初のものを使用します:

1. 生ノートファイル — フェーズ B ステップ4 から。
2. 設定済みソース — agent-config → ミーティングノートソース の各エントリを順に。代表的なもの:
   • カレンダー添付ファイル — イベントに添付されたノートドキュメント → files.read をファイルIDで実行。「見つかりません」はユーザーと共有されていないことを意味します — 静かにスキップします
   • docs.meeting_notes(日付) — タイトルまたは時間枠 (±30分) で一致; docs.read で読み込み
3. カレンダーイベントの説明 — 実際のノートが含まれている場合にのみ使用します (単なるアジェンダやビデオリンクではない場合)。
4. ユーザーに尋ねる — まだコンテンツのないミーティングを1つのメッセージにリストアップします: "次のミーティングのノートが見つかりません: [リスト]。ダイジェストしたいミーティングのノートまたはトランスクリプトを貼り付けるか、スキップと言ってください。"

ミーティングにまだコンテンツがない場合 → "利用可能なノートなし" とマークしてスキップします。

フェーズ D — 報告

すべてのミーティングを処理した後、以下を報告します:

• ダイジェストされた数
• スキップされた数 (理由付き: 既に存在する / ノートなし)

---

ステップ 2 — コンテキストを読む

ノートコンテンツを処理する前に、以下を読んでください:

• GOALS.md — アクティブなプロジェクトと目標を理解するため
• Context/Memory/brain.md — ユーザーの考え方、語彙、何を決定事項とみなし、何を議論とみなすかを理解するため

---

ステップ 3 — ノートコンテンツを分析する

コンテンツのある各ミーティングについて、4つの要素を抽出します:

A. 要約 2～3文。シグナルファースト: ミーティングの目的と、主要な成果または変化は何か。取り上げたトピックのリストではなく、1つの一貫した成果ステートメント。ユーザーの口調を使用: 直接的で、努力の枠組みはなく、結果から始めます。

B. 決定事項 方向性を変えたり、何かを確定させたり、未解決の質問を閉じたりした明確なコミットメント。実際の決定事項のみ — 提案や可能性のあるものは含みません。形式: 何が決定されたか、誰が決定したか (属性が可能な場合)。

C. アクションアイテム 名前付きの所有者がいる具体的な次のステップ。各アイテムに次のロジックを適用:

• ノートが特定の人物を自信を持って担当者として指名している場合 → その人物に割り当てる
• 所有権があいまいまたは共有されている場合 → ユーザーに割り当てる
• プロジェクト管理アイテムまたはプロジェクトは、ミーティングで明示的に言及された場合のみ含める (キー、名前、または明確な参照による)。推測や類推はしないでください — 言及されていない場合は、Project 列を空白 (—) のままにします
• ミーティングで言及された提案された期日を記録します。それ以外は空白のままにします

D. 未解決の質問 / ブロッカー 未解決の質問、提起されたブロッカー、または将来のミーティングのために保留されたトピック。これらはノートファイルにのみ記録されます。

---

ステップ 4 — プロジェクト参照

アイテムキーまたはプロジェクト名は、ミーティングで明示的に言及された場合のみ記録します — キー (例: ENG-123)、名前 (例: 「オンボーディング刷新マイルストーン」)、または明確な参照による。

ミーティングのコンテキストからプロジェクトを推測、検索、または類推しないでください。間違ったものを割り当てるよりは、空白のままにする方が良いです。

---

ステップ 5 — ミーティングノートファイルを書き込む

ダイジェストを Context/Meeting Notes/ に以下のファイル名形式で保存します: YYYY-MM-DD - [ミーティング名].md

カレンダーイベントの summary をミーティング名として使用します。

ファイル形式:

# [ミーティング名]
*[YYYY-MM-DD] | [利用可能な場合の時間] | [利用可能な場合のカレンダーの参加者]*

## Summary
[2～3文のシグナルファーストの要約。何が起こったか、何が変わったか。]

## Decisions
- [決定事項1 — わかっている場合は誰が決定したか]
- [決定事項2]

## Action Items
| # | タスク | 所有者 | プロジェクト | 期日 |
|---|------|-------|---------|-----|
| 1 | [タスクの説明] | [名前 / me] | [プロジェクト名 (KEY-123) または —] | [日付または —] |
| 2 | ... | ... | ... | ... |

## Open Questions & Blockers
- [質問またはブロッカー — 何が未解決で、なぜそれが重要なのか]

## Context
[ミーティングからの背景、リンク、または将来の参照に役立つ枠組み。最大3～5箇条書き。]

ソースが生ノートだった場合 (フェーズ B ステップ4)、それらを ## Raw notes セクションの下に保持します — ユーザーのノートを決して削除しないでください。

保存する前に、Obsidianのグラフ接続性のためにノートに [[wiki-links]] を追加します:

• 名前で言及されたすべての人物 → [[名前]]
• すべてのアイテムキー → [[KEY-123]]
• ノート間で繰り返し登場する主要な概念、プロジェクト、テーマ → [[概念]]
• 意味のある言及のみをリンクします — すべての単語ではなく、コードブロックやURL内は除外します

ユーザーに確認します: "ミーティングノートを Context/Meeting Notes/[filename].md に保存しました。"

---

ステップ 6 — タッチへの複合

保存後:

1. このミーティングの決定事項またはブロッカーが Tasks/ の未完了タスクに関連するか確認します — 関連する場合は、その場で注記します。
2. ブロッカーが既に GOALS.md に既知のブロッカーとして存在する場合、フラグを立てます: "このブロッカー ([名前]) は [以前のコンテキスト] でも提起されました。体系的なものかどうか検討してください。"
3. ミーティングが Context/121s/ にドキュメントを持つ名前付きの人物との定期的な1on1である場合、そのドキュメントにセッションログエントリを追加します: 日付、1行の要約、追加された未解決のループ。

ミーティングノートには個人データが含まれており、コミットまたはプッシュされることはありません。

---

ステップ 7 — チャットに要約を表示

すべてのノートをローカルに保存した後、1日のダイジェスト全体の1つの結合された要約を表示します。

構造: ミーティング → トピック → 各トピックの下の決定事項 + アクション。

📝 **ミーティングダイジェスト完了 — [YYYY-MM-DD]** | [N] ダイジェスト | [N] スキップ

*[ミーティング名]*
  [トピック / 目標またはマイルストーン]
    決定事項
      - [決定事項]
      - [決定事項]
    アクションアイテム
      - [タスク] → [所有者] [期日があれば]

  [トピック2]
    決定事項
      - [決定事項]
    アクションアイテム
      - [タスク] → [所有者]

ノートは `Context/Meeting Notes/` に保存されました

グループ化ルール:

• トップレベル: ミーティング名
• 第2レベル: そのミーティング内で議論されたトピック、目標、またはマイルストーン — プレーンな名前を使用し、イシューキーだけは使用しない
• 第3レベル: 決定事項 と アクションアイテム を各トピックの下のラベル付きサブセクションとして
• トピックに決定事項がない場合、決定事項サブセクションは省略します。アクションアイテムがない場合、アクションアイテムサブセクションは省略します。
• ミーティングにトピックが1つだけの場合でも、トピック名を表示します — 省略しないでください
• アクションアイテムから Project 列をチャット要約では省略します — これはノートファイルのみに属します

---

ステップ 8 — 決定ログ更新の提案

このステップは、ダイジェストされたすべてのミーティングで少なくとも1つの決定事項が抽出された場合のみ実行されます。

1つのメッセージで一度だけ尋ねます:

"これらの決定事項をPRDの決定ログに記録しますか？

今日の決定事項:

[ミーティング名] [トピック] 1. [決定事項] 2. [決定事項]

はいの場合、どのドキュメント (ローカルファイルの Context/Document Hub/ またはドキュメントツールのページ) と、どの決定番号を追加するか教えてください。"

すべてのミーティングにわたって決定事項に連番を振り、ユーザーが番号で参照できるようにします。

ユーザーの応答を待ちます。

• いいえ / スキップの場合: スキルを終了します。
• はいの場合: 指定された各ドキュメントについて以下の手順を続行します。

---

提供された各ドキュメントについて:

A. ドキュメントを取得

• ローカルファイル → 読み込み。
• ドキュメントツールのページ → docs.read。

B. 決定ログを見つける

見出しに「Decision Log」「Decisions Log」「Decisions」を含むセクションをスキャンします (大文字小文字を区別しない)。

• テーブルが存在する決定ログセクションがある場合: 新しい行をそこに追加します。
• 決定ログセクションはあるがテーブルがない場合: 見出しの直下にテーブルを挿入します。
• 決定ログセクションが存在しない場合: ドキュメントの下部に新しい ## Decision Log セクションとテーブルを挿入します。

C. 行を作成

ユーザーが選択した各決定事項について、1つのテーブル行を作成します:

| [YYYY-MM-DD] | [決定事項テキスト] | [ステータス] |

• 日付: ミーティングの日付。
• 決定事項: ダイジェストからそのままのテキスト — 言い換えないでください。
• ステータス: 明示的かつ最終的な場合は Decided。テキストに「TBD」「to be confirmed」「pending」「waiting on」が含まれるか、未解決とマークされている場合は Pending。

テーブルがまだ存在しない場合は、最初にこのヘッダー行を作成します:

| 日付 | 決定事項 | ノート/ステータス |
|------|----------|--------------|

D. プレビューしてから更新

追加される行を表示します。ローカルファイルの場合は書き込みます。ドキュメントツールのページの場合は、ユーザーの明示的な OK を待ち、その後 docs.update(ref, "Decision Log", rows) でそのセクションのみを変更します。

E. 確認

"決定ログが [ドキュメントタイトル] で更新されました — [N] 件の決定事項を追加しました。"

---

エッジケース

• 決定事項が見つからない場合: 「決定事項なし — 議論/更新ミーティング。」と書き込みます。決定事項をでっち上げないでください。
• アクションアイテムが見つからない場合: 「アクションアイテムなし。」と書き込みます。
• ミーティングがスタンドアップまたは5分未満の場合: それでもダイジェストは実行しますが、要約は1文に抑えます。
• 同じイベントに複数のノートが一致する場合: イベントの開始時刻に最も近いものを使用します。
• ソースが利用できない場合: 静かにスキップし、フェーズCの次のソースにフォールスルーします。
• ドキュメントページが見つからない場合 (ステップ8): エラーを報告し、ユーザーにURLを再確認するよう求め、再試行を提案します。
• 決定ログセクションがあいまいな場合 (ステップ8): 複数の見出しが一致する可能性がある場合 (例: 「Key Decisions」と「Decision Log」)、両方を表示し、どちらに追加するか尋ねます。
• 重複した決定事項 (ステップ8): 挿入する前に、既存の行をスキャンします。同じ決定事項テキストが既に存在する場合、それをスキップし、スキップしたことを注記します。