Member C Digest

member-c-digest スキル

member-c（Slack ID: U_MEMBER_C）から me（U_SELF）、または所属グループ（group_alpha / group_designer / group_beta）へのメンションを収集し、内容の要約とアクション依頼を抽出して表示する。あわせて Figma アプリの DM から member-c のコメント通知も取得する。メッセージ内にリンクされた Notion ページがある場合は notion-fetch で読み込み、内容を補足する。

実行手順

1. 日数の決定

引数が指定されている場合（例: 3d, 7d, 14d）はその日数を使用する。 指定がなければデフォルトは 7日。

今日の日付をもとに対象期間の開始タイムスタンプ（Unix 秒）と after:YYYY-MM-DD の日付を算出する。

注意: Slack の after: フィルターは指定日を含まない（翌日以降が対象）。 そのため「N日前まで遡る」場合は、(N+1)日前の日付を使う。 例: 過去7日 → after:（8日前）、昨日〜今日 → after:（2日前）

2. データ取得（並行実行）

以下を同時に実行する：

Slack 検索（1クエリ・広く引く） — slack_search_public_and_private を使用：

• from:<@U_MEMBER_C> after:YYYY-MM-DD

⚠️ メンション文字列やグループ名をクエリに足さない（後述の「4クエリの罠」）。絞り込みは取得後に行う。

パラメータ：

• sort: timestamp
• sort_dir: desc
• include_bots: false
• limit: 20（最大値）

limit は最大20。20件返ったら cursor で次ページを取り、対象期間の最古に届くまで繰り返す。

⚠️ 「4クエリの罠」（2026-09-04 実測で判明・元に戻さないこと）

旧仕様は from:<@U_MEMBER_C> <@U_SELF> after:日付 等の4クエリで、メンション文字列を本文のキーワードとして AND 検索していた。相手がスレッド内で返信した場合は本文にメンションが入らないため、まるごと取りこぼす。

実例＝2026-09-02 の member-a のやりとり（#proj-alpha-feature）は、新手順で6件ヒットしたが内訳は (a)0件 / (b)0件 / (c)6件＝旧手順では全滅していた。

このためこれ以前の digest の「0件」は信用できない（本当に0件か取りこぼしかを区別できていない）。

Figma コメント取得（2経路） — Slack DM通知 + REST API で取りこぼしを防ぐ：

(a) Figma DM 通知 — slack_read_channel を使用：

• channel_id: D_FIGMA_DM（Figma アプリの DM チャンネル）
• limit: 50
• 1ページで対象期間の最古に届かない場合は cursor で次ページを取得して補う

(b) Figma REST API（必須・メンション未着のコメントも拾う）— Bash で実行：

FIGMA_TOKEN=$(security find-generic-password -s "FIGMA_TOKEN" -w)
curl -s -H "X-Figma-Token: $FIGMA_TOKEN" \
  "https://api.figma.com/v1/files/YOUR_FIGMA_FILE_KEY/comments"   # Project Alpha（既定ウォッチ対象）

• 通知本文・コメント内に生URL（figma.com/design/<KEY>）があれば、その <KEY> も対象に追加
• レスポンス comments[] から member-c 本人のコメントを抽出（created_at が対象期間内のみ）。 ⚠️ REST API の user.handle は Figma の表示名で、Slack ハンドルとは別物。member-c は Member C（推定・Figma上の表記未確認）。揺れに強くするため Member C / Member C / member-c のいずれかを含むかで判定する。
• 401/404/トークン無しは graceful skip（DM通知のみで続行・その旨を注記）

取得後、ts / created_at が対象期間内のものだけに絞り込む。(a)(b) はマージして重複排除（commenter + message先頭40字 + 時刻60秒以内をキー、REST優先）。
member-c（Slack U_MEMBER_C / Figma 表示名 Member C（推定））からのコメントのみを対象とし、他者の返信は「コンテキスト」として参照するにとどめる。

3. 結果の統合・重複排除

Slack 検索の結果を message_ts で重複排除し、対象期間内に絞る。そのうえで、本文の文字列ではなく宛先と関与で判定して、次のいずれかに該当するものだけを残す：

• (a) 本文に <@U_SELF> を含む（自分への直接メンション）
• (b) 本文に group_alpha / group_designer / group_beta を含む（グループ宛）
• (c) 自分が関与しているスレッド内の発言 — thread_ts を持つメッセージについて slack_read_thread で親スレッドを引き、親または他の返信に <@U_SELF> か自分（U_SELF）の発言があるなら残す
• (a)(b)(c) のどれにも当たらないものは除外する（相手が別件で書いただけのものはノイズ）
• (c) の判定でスレッドを読むのは、(a)(b) で既に残ったものを除いた残りだけでよい（無駄な取得を避ける）

残ったものを Figma DM の結果と合わせてタイムスタンプ降順にソートする。

Slack メンションと Figma コメントは別セクションで出力する。

3.5. スレッドリプライの取得（並行実行）

重複排除後の Slack メンション のうち reply_count > 0 のものを抽出し、以下を すべて並行 で実行する：

各メッセージに対して slack_read_thread を使用：

• channel_id: メッセージが属するチャンネル ID
• thread_ts: メッセージの ts（= スレッド親メッセージのタイムスタンプ）
• limit: 20

取得したリプライは、親メッセージの ts をキーとして紐づけて保持する。
reply_count が 0 のメッセージ、または Figma DM のメッセージはこのステップをスキップする。
ステップ3の (c) 判定で既に slack_read_thread を実行したスレッドは再取得しない（その結果を再利用する）。
slack_read_thread がエラーを返した場合は graceful skip（そのメッセージを通常通り処理）。

4. Notion リンクの取得（並行実行）⚠️ 必須・スキップ禁止

このステップは分析（ステップ5）の前に必ず実行すること。

以下の両方を対象に notion.so の URL を探し、見つかったものをすべて並行で notion-fetch する：

1. 親メッセージ本文（重複排除後の全 Slack メンション）
2. スレッドリプライ本文（ステップ 3.5 で取得した全リプライ）

チェックリスト（分析前に確認）:

• 親メッセージに notion.so URL があれば取得した
• スレッドリプライ内に notion.so URL があれば取得した
• 取得した Notion ページの内容を該当メッセージと紐づけて保持した

Notion URL が1件もない場合のみこのステップをスキップしてよい。

5. 各メッセージの分析

各メッセージ（および取得した Notion ページの内容、スレッドリプライ）に対して以下を行う：

概要（1〜2文）: メッセージ本文・Notion の内容を読み、何についての話か日本語で簡潔に要約する。スレッドリプライがある場合は「スレッド X 件（参加者 Y 名）」を概要末尾に付記する。

スレッドリプライの分析（reply_count > 0 の場合）: スレッド全参加者の発言を読み、以下を追加で抽出する：

• member-c 以外の参加者から me / group_alpha / group_designer / group_beta への追加アクション依頼
• スレッド内で決定・合意された事項（あれば）
• 未解決の論点・継続議論（あれば）

アクション依頼の抽出: me / group_alpha / group_designer / group_beta に対して「何をしてほしいか」を明確に抽出する（スレッド内の依頼も含む）。Notion が仕様書・設計書の場合はレビューすべき箇所の URL も合わせて示す。依頼がない場合は「情報共有のみ」と記載する。

価値仮説の推定（アクション依頼がある場合のみ・「情報共有のみ」の場合は不要）: 依頼内容・メッセージ・Notion の内容をもとに以下を各1文で推定する。

• 欲求: 依頼者が本当に達成・解決したいこと（HOW／手段は入れない）
• 課題: 欲求を満たすのを妨げている状況の制約（「〜ないため」の形）

優先度の判断: 以下の基準で ★〜★★★ を付ける：

• ★★★: 期限・締め切りの言及がある、または強い言い回し（「お願いします」「確認していただきたい」など）
• ★★: 依頼や質問がある
• ★: 情報共有・CC

6. 出力フォーマット

Slack メンションと Figma コメントをセクション分けして出力する：

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📨 member-c からの Slack メンション（過去 N 日間: X 件）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[1] ★★★ 2026-05-18 18:26 | #proj-alpha-all
概要: Feature AのScreen Aの仕様変更について、Notion 仕様書（v1.2）を更新したのでレビューを依頼。スレッド 30 件（参加者 5 名）。
依頼: 以下の Notion 仕様書にレビュー・コメントをお願いしたい。
  📄 仕様書全体: https://www.notion.so/...
欲求推定: 仕様の認識齟齬を事前につぶして実装品質を担保したい
課題推定: 仕様書の変更点を関係者が個別に確認しないと漏れが生じるため
💬 スレッド: 30件のリプライ — 決定: 〇〇 / 未解決: △△
🔗 https://your-workspace.slack.com/archives/...

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🎨 member-c からの Figma コメント（過去 N 日間: Y 件）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[1] ★★★ 2026-05-18 17:23 | Project Alpha
概要: Screen A のボタンの遷移先がリストページになっており挙動がおかしいと指摘。
依頼: 遷移先の設計意図を確認・修正してほしい。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
合計 アクション必要: X 件 / 情報共有のみ: Y 件
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

フォーマットルール:

• スレッドリプライがある Slack メッセージには 💬 スレッド: 行を追加する
• 💬 スレッド: 行には件数・決定事項・未解決の論点のうち該当するものを記載する。すべて不明の場合は「N 件のリプライ」のみ記載
• Figma コメントにはスレッド行を追加しない（Figma DM はスレッド構造を持たないため）

Slack・Figma ともに0件の場合は「過去 N 日間に member-c からのメンション・コメントはありませんでした。」と表示する。