# Member A Digest

> member-a（Member A）からの Slack メンションと Figma コメント通知を収集し、概要とアクション依頼をまとめて表示する。リンクされた Notion ページも読んで内容を補足する。引数で日数指定可能（例：/member-a-digest 3d）。

- Skill: `sugawaramasaya/member-a-digest` (Agent Skill)
- Install (CLI): `npx skillmds@latest add sugawaramasaya/member-a-digest`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sugawaramasaya/member-a-digest/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Design & Media
- Author: sugawaramasaya (https://skillmd.com/u/sugawaramasaya)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/sugawaramasaya/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 で実行：
```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` へのシェル引用崩れを避けるため）:

```bash
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 に日本語・引用符が含まれるため）:

```bash
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 側でユーザーが編集・完了・アーカイブ済みのタスクを上書き復活させない）。