Member A Digest

member-a-digest スキル

member-a（Slack ID: U_MEMBER_A）から me（U_SELF）、または所属グループ（group_alpha / group_designer / group_beta）へのメンションを収集し、内容の要約とアクション依頼を抽出して表示する。あわせて Figma アプリの DM から member-a のコメント通知も取得する。メッセージ内にリンクされた 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_A> 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_A> <@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-a 本人のコメントを抽出（created_at が対象期間内のみ）。 ⚠️ REST API の user.handle は Figma の表示名で、Slack ハンドルとは別物。member-a は Member A（全角スペース）。揺れに強くするため Member A または member-a を含むかで判定する。
• 401/404/トークン無しは graceful skip（DM通知のみで続行・その旨を注記）

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

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

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

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

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

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

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

6. 出力フォーマット

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

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📨 member-a からの 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-a からの 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-a からのメンション・コメントはありませんでした。」と表示する。

Council 連携（Activity への自動書き出し）

ターミナルへの表示が完了したら、収集・要約した内容を Council アプリの Activity フィードにも書き出す。

• 対象: 上記フォーマットで表示した Slack メンション・Figma コメントの全体を1エントリにまとめる（件数分バラさない）。
• Slack・Figma ともに0件の場合は書き出しをスキップする（ヘルパーを呼ばない）。
• エントリ内容:
  • kind: "digest"
  • source: "member-a-digest"
  • title: "member-a N件（主な案件）" 形式（N は合計件数、主な案件は最も優先度の高い1件の概要を短く）
  • summary: 全体の要約（1〜2文。★★★案件があれば優先して触れる）
  • action_items: 抽出した「依頼」文をすべて配列にまとめる（「情報共有のみ」の項目は含めない）
  • project: 主な案件名（複数ある場合は最頻出 or 最優先のもの1つ）
  • links: 収集した Slack/Figma/Notion の URL（重複排除）

呼び出しは、JSON に日本語・引用符・改行が含まれるため stdin パイプを推奨する（--entry へのシェル引用崩れを避けるため）:

cat <<'JSON' | node ~/.claude/scripts/council-activity-append.js
{
  "kind": "digest",
  "source": "member-a-digest",
  "title": "member-a 3件（Feature Aレビュー依頼ほか）",
  "summary": "Feature AのScreen Aの仕様変更レビュー依頼が中心。Figmaで遷移先不具合の指摘も1件。",
  "action_items": [
    "Notion仕様書v1.2のレビュー・コメント",
    "Screen A のボタンの遷移先設計意図の確認・修正"
  ],
  "project": "Project Alpha",
  "links": [
    {"url": "https://your-workspace.slack.com/archives/...", "label": "Slack: Feature Aレビュー依頼"}
  ]
}
JSON

id/ts/date は指定しない（ヘルパーが自動補完し、実行ごとに新規エントリとして積む）。

Board へのタスク切り出し（AI選別・自動）

Activity への書き出しに続けて、抽出した action_items の中から タスク化すべきものだけを選別し、1件ずつ council-task-append.js に渡す（Council アプリの Board に Task として現れる）。

• 選別基準: 「自分（me）が実行すべき具体的な作業」で「未完了」のもの。以下は除外する：
  • 単なる情報共有・FYI（「情報共有のみ」と判定した項目）
  • すでに返信・対応済みで完結しているもの
  • member-a 本人や他者が実行すべきタスク（自分向けではない依頼）
• priority: 依頼元の ★ 優先度から機械的に変換する：★★★→high / ★★→medium / ★→low（★=情報共有は基本的に選別基準で除外される想定）。
• activity_source: "member-a-digest" 固定。
• 選別後の対象が 0件ならヘルパーを呼ばない。
• 呼び出しは依頼1件=1回、stdin パイプ推奨（JSON に日本語・引用符が含まれるため）:

cat <<'JSON' | node ~/.claude/scripts/council-task-append.js
{
  "title": "Notion仕様書v1.2のレビュー・コメント",
  "priority": "high",
  "activity_source": "member-a-digest"
}
JSON

対象が複数ある場合は、この呼び出しを依頼ごとに繰り返す（id は title+activity_source から決定的に生成されるため、同じ依頼を再実行しても増殖せず、Board 側でユーザーが編集・完了・アーカイブ済みのタスクを上書き復活させない）。