foundation-meeting-synthesize

会議の統合分析

会議の統合分析は、複数回にわたる取り組みを対象とする考古学的な分析スキルです。一定期間の会議の要約（必要に応じて生のメモも）を読み込み、単独の会議では明らかにならないパターン、つまり意思決定がどのように変化したか、関係者の立場がどう変わったか、どの議論が停滞しているか、どこで矛盾が生じているかを明らかにします。

/discover-interview-synthesis とは異なります。このスキルは、ジョブ理論や購買に関するインサイトなど、リサーチ固有のフレームワークを用いてユーザーリサーチの会話を扱います。一方、このスキルは、関係者の合意形成、意思決定の変化、プロジェクトの経緯など、組織固有のパターンを用いて社内会議を扱います。

このスキルは会議スキルファミリーに属します。会議スキルファミリーの契約に準拠しています。

使用する場面

• 一連の会議を横断した、取締役会の準備や経営幹部向けブリーフの作成
• 新しいチームメンバーへの取り組みの経緯の共有
• プロジェクトの振り返り資料（これまでの経緯の整理）
• 複数回の会議にわたる取り組みが停滞している理由の調査
• 多数の会議で扱われてきたトピックの四半期レビュー
• 単独会議のレビューでは見つからなかった矛盾の発見

使用しない場面

• 単一の会議の要約。代わりに foundation-meeting-recap を使用してください。
• 成果を社外に伝える場合。代わりに foundation-stakeholder-update を使用してください。
• ユーザーリサーチの会話の統合分析。代わりに discover-interview-synthesis を使用してください。

手間のかからない実行

ファミリーの契約に従い、このスキルは質問を重ねて処理を止めることはありません。デフォルトの流れは次のとおりです。

1. 提供されたすべてのソースファイルを読み込む（要約を優先し、生のメモも受け付けますが、入力品質フラグは低くなります）
2. フィルター（期間、トピック、関係者）を適用する
3. テーマ、関係者の変化、矛盾について推論する
4. 推論の概要を提示する（フィルター適用後の会議数、検出された期間、ソースごとの入力品質、適用した範囲フィルター）
5. go または修正を受け付ける
6. 統合分析を作成する

--go を指定して実行した場合は、推論の概要を省略します。形式のヒント（board-prep、onboarding、retro-input、exec-brief）は、基礎となるプロセスを変更せずに出力形式を調整します。

手順

会議の統合分析を作成するよう依頼された場合は、次の手順に従ってください。

1. ソースを読み込む 提供されたすべての会議要約ファイルまたはメモファイルを読み込みます。フロントマターを解析して会議のメタデータを抽出します。ソースごとの入力品質を記録します（利用可能な場合は要約のフロントマターにある input_quality を使用し、ない場合は内容から評価します）。

   メタデータのソース追跡（v1.1.0）：各要約について、meeting_type_source フィールド（explicit | inferred | null）も記録します。複数のソースを統合する場合は、「meeting_type values: N explicit, M inferred, K null.」という形式で、統合分析の「範囲」セクションに内訳を明記する必要があります。これにより、確信度が異なるソースが混在している場合に、meeting_type によるフィルタリングの結果が再現できなくなることを防ぎます。meeting_type でフィルタリングする場合は、推論された値をフィルターに含めるかどうかと、null 値をどう扱うかを明記してください。

2. フィルターを適用する 期間、トピック、または関係者のフィルターが指定されている場合は、先にソースを絞り込んでから次に進みます。適用したフィルターをフロントマターの scope_filter に記録します。

3. 推論の概要を提示する フィルター適用後の会議数、ソースのメタデータから検出された期間、ソースごとの入力品質レベル、範囲フィルターの説明を示します。

4. プレーンテキストのタイムラインを作成する meeting_date の時系列順に並べます。各項目には日付、会議名、主な決定または変化を記載し、該当する場合は確信度または矛盾のフラグを付けます。Markdown として表示します（バイナリー画像は使用しません。どこでも表示できる必要があります）。

5. テーマを抽出する 複数のソースに繰り返し登場するトピックを分類します。各テーマについて、説明、登場したソース、頻度に基づく確信度マーカーを記録します（「5/5 件の会議で登場」→高、「2/5 件の会議で登場」→中、「1 件の会議で言及」→低）。

6. ステークホルダーの立場を追跡する ソース全体にわたる各名称付きステークホルダーについて、初期の立場 → 現在の立場、整合状態（整合 / 相違 / 変動中）、および日付付きの主要な発言を記録します。各立場について、直接引用か言い換えかに基づいて信頼度にフラグを立てます。

7. 決定事項を統合する 会議を横断して、時系列順に並べます。表形式：日付 | 決定事項 | 文脈 | 会議 | 信頼度。

8. 決定の変遷と未解決の矛盾を分離する（v1.1.0） 1 つの統合された「矛盾」セクションではなく、2 つの別個の出力とします：

   • 決定の変遷（解決済み）：同じトピックに関する以前の決定 → 後の決定で、後のものが以前のものを置き換えるもの。これは歴史的な文脈であり、危険信号ではありません。⚠ による強調は行いません。
   • 未解決の矛盾：現在衝突しており、調和が必要な決定または立場。⚠ による視覚的強調を使用します。それぞれについて：
     • 以前の参照（会議 + 日付 + 決定）
     • 後の参照（会議 + 日付 + 衝突する決定）
     • ステータス：未解決 / 調和が必要

   この区別が重要である理由は、v1.0.0 では両者を混同していたため、経営層の文脈において「矛盾」が実際には意図的なスコープの変遷であったにもかかわらず、偽陽性の「矛盾」を生み出していたからです。

9. 未解決項目と停滞しているスレッドを特定する 解決されないまま 2 回以上表面化したトピック。それらが最後に現れた時期。

10. ナラティブサマリーを作成する 2〜3 段落：何が起きたか、何が変わったか、どこにいるか、何が懸かっているか。会議セットの「ストーリー」。

11. フォローアップ提案に優先順位を付ける

    • 高：今すぐブロックを解除するもの。推奨される担当者またはフォーラム
    • 中：重要だがブロッキングではないもの
    • 低：監視 それぞれに根拠を付けます。

12. フォーマットヒントを適用する（提供された場合） 1 つのプロセスが完全な統合データを生成します。ヒントは特定のユースケースに対するセクションの順序と切り詰めを制御します：

    • board-prep：ナラティブ + 矛盾 + 優先順位付きフォローアップを先頭に。タイムラインは短め
    • onboarding：ナラティブ + ステークホルダー追跡を先頭に。完全なタイムライン
    • retro-input：テーマ + 停滞しているスレッド + 会議品質の集計を先頭に
    • exec-brief：TL;DR + 上位 3 項目のみ

13. TEMPLATE.md をレンダリングして検証する

    • source_meetings リストが空でない
    • time_range.start ≤ time_range.end
    • すべてのテーマに信頼度マーカーがある
    • すべての矛盾に before/after のソース引用がある
    • 優先順位付きフォローアップが少なくとも 1 つある

プロジェクトメモリ契約

.claude/pm-skills.local.md が存在する場合にのみ有効です。ファイルがない場合は、このセクションを完全に無視し、上記で説明したとおりに動作します。

• 読み取り： active_initiative および同じトピックに関する以前の interpretation アーティファクト。これにより、統合はすでに記録されている内容を繰り返すのではなく、動きを示します。
• 書き込み： 統合を interpretation アーティファクトとして書き込みます。
• 姿勢： エントリを提案し、書き込む前に確認を待ちます。ただし memory_auto_append: true が設定されている場合は、追記して書き込んだ内容をエコーします。
• 書き込みの規律： 書き込む直前にファイルを再読み取りし、提案を生成したコピーからは決して行いません。その間に変更されていた場合は、自分のエントリを現在の状態にマージし、上書きするのではなく再提案します。自分のエントリのみを追加し、他のすべてのフィールドとセクションはバイト単位で同一のままにします。これをランタイムで強制するものはなく、ファイルは gitignore されているため、不注意なファイル全体の書き込みは、別のセッションの作業を復元不可能な形で失わせます。

これは、このファミリーのファイル名ベースのチェイニングを置き換えるものではなく補完します。ファイル名は依然として 1 つの会議の兄弟アーティファクトを特定し、プロジェクトメモリは会議をまたいで永続的なプロダクトコンテキストを運びます。

品質チェックリスト

• ソースとなる会議がファイル名、日付、ソースごとの入力品質とともに記載されている
• 時間範囲が設定され、妥当である
• 対象範囲のフィルターが説明されている（または「適用なし」）
• タイムラインがプレーンテキストの Markdown である（バイナリー画像を含まない）
• テーマに、頻度に基づいた信頼度マーカーが付いている
• ステークホルダーの立場の追跡で、スナップショットだけでなく変化（当初 → 現在）が示されている
• 統合された決定事項の一覧が時系列順で、ソースの引用が付いている
• 矛盾が独立した主要セクションで明示されている（埋もれていない）
• ナラティブ形式の要約が箇条書きではなく、2～3段落である
• フォローアップに優先度（高／中／低）とその理由が付いている
• フロントマターに、単一会議向けのフィールド（meeting_title、meeting_date など）が含まれていない
• Sources と References で、ソース全体にわたる入力品質が考慮されている

関連項目

• 会議スキルファミリーの契約
• foundation-meeting-recap。上流：主要な入力ソース
• /discover-interview-synthesis。ユーザーリサーチの会話向けの兄弟パターン（対象分野は異なります）