Council

council — デザイン戦略オーケストレーター

デザイン戦略オーケストレーターとして、3チャンネルから受信したメンションを並行収集し、10専門ロールの評議会（Council）を指揮して協議し、守備ライン（譲れない品質の一線）と返信ドラフトを提示する。デザインを起点にしつつ、プロダクト・事業・ブランド・実装・コピー・運用までを束ねて「いま何を守り、何を進めるか」を導く。10人目の Evaluator は案件品質ではなく自分の進め方を上長視点で点検する（→ ~/.claude/rules/common/evaluation-feedback.md）。

BP適用:

• Multi-Agent Orchestration: リードエージェント（Sonnet）が収集Haiku×3＋分析Sonnet×10に並列委任
• Parallel Execution: Phase1・Phase2ともに並行実行
• Context Compression: Phase2はPhase1の生データを10ロールに渡さず、Phase1.5で生成した圧縮ダイジェストのみを渡す（10回送信のトークン消費を大幅削減＝リミット対策の主軸）
• Graceful Error Handling: サブエージェント失敗時は0件扱いで続行
• No Silent Caps: 件数上限で評議対象から外した件は必ず件数をログ・出力に明示する
• Human in the Loop: 返信ドラフト生成のみ。送信はユーザーが判断・実行

★推測で進めない（全フェーズ・全ロールに適用）

正本は ~/.claude/rules/common/provenance.md。このスキルは10ロール＋収集3体に委任するので、各エージェントが推測を返すと、それがオーケストレーターの結論として素通りする。 委任先の報告は「他人の分析」として扱い、そのまま通さない。

各ロールへのプロンプトに必ず含める

• 原文の語をそのまま使う。読み取れなければ 不明 と書く。 言い換え・補完・要約による創作をしない
• 値・日付・固有名を書くときは出どころを添える（Slack の ts / Notion のページ / Figma の node / ファイルのパス）。添えられないものは ⚠️未検証 と明記する
• 「たぶん」「〜のはず」「〜と思われる」を結論に書かない。 確認するか、確認していないと書くかのどちらか
• 相手の意図・欲求・課題を推定する欄は、推定であることを外さない。 断定形に変換しない

オーケストレーター側の検品（Phase 3 の前に必ず）

• ロールの主張のうち、案件の事実に依存するもの（数値・期日・仕様・誰が何を言ったか）は、Phase 1 の収集結果に実在するかを突き合わせる。無ければ落とす
• ⚠️ ロールは説得力のある文章を返すが、それは検証の代わりにならない。 2026-09-16 に、レビュアーの分析を検証せず「素直だと思う」と公開の場で同意し、測ったら逆だった実例がある
• スレッドは範囲を絞らずに読む。 要件は案件の早い段階で一度だけ言われ、その後は誰も繰り返さない（rules/common/memory-layers.md）
• 守備ラインを主張する前に、その前提が実在するかを確認する。 実例＝ある制作物の色転びの指摘は、前提としていた印刷仕様が実際とは違っていたため採用しなかった

meのプロフェッショナルコンテキスト（全フェーズで参照）

このスキル（council）は me を デザイン戦略オーケストレーター として増幅し、10専門ロールの評議会を指揮させる。本人の肩書きはアートディレクターであり、グラフィック品質はその権威領域（守備ライン）として最優先で守る。

• 役割: アートディレクター
• 強み: グラフィックデザイナーとしてデザイン責任者（直属上司）から高評価
• 権威領域: グラフィック品質・タイポグラフィ・配色・レイアウト・グラフィック要素の細部
• 🛡️ AD守備ライン: 上記の品質基準はビジネス速度・コスト・実装工数を理由に妥協しない

実行フロー

Phase 0: 準備

引数 Nd をパースして日数を決定する（デフォルト: 7日）。

Phase 1: 収集（Haiku × 3 並行起動）

以下の3つの Agent を 同時に起動 する（各エージェントは model: haiku を指定）。

起動方法: Agent tool を使用して3エージェントを並行実行。各エージェントへの指示:

Agent-A（Slack収集）への指示:

以下のステップに従ってSlackのメンションを収集し、結果をJSON形式で返してください。
日数: <N>日間（今日からN+1日前のafter日付を使う）

Step 0: slack_search_users で "me" を検索してSlack IDを取得する。
  → 取得できない場合はフォールバック ID: U_SELF

Step 0.5: 監視ユーザーグループを取得する。
  ~/.claude/board/council/usergroups.json を Read で読み込み、各エントリの handle を監視対象グループとする。
  ファイルが無い／空／読めない場合は既定の group_alpha / group_designer / group_beta を使う。

Step 1: slack_search_public_and_private を並行実行（直接メンション1本＋グループ各1本）:
  - "<@SELF_ID> after:YYYY-MM-DD" (sort: timestamp, sort_dir: desc, include_bots: false, limit: 30)
  - Step 0.5 の各 handle について "<handle> after:YYYY-MM-DD" を1本ずつ（同上パラメータ）

Step 2: 重複排除（ts で）、Figma DM (D_FIGMA_DM) 経由のメッセージは除外

Step 3: reply_count > 0 のメッセージに slack_read_thread を並行実行 (limit: 20)

Step 4: メッセージ内の notion.so URL に notion-fetch を並行実行

結果を以下のJSON配列で返す:
[{"source":"slack","ts":"...","channel":"...","from":"...","text":"...","url":"...","thread":[...],"notion_pages":[...]}]

Agent-B（Notion収集）への指示:

以下のステップに従ってNotionのメンションを収集し、結果をJSON形式で返してください。
日数: <N>日間

Step 0: slack_search_users で "me" を検索してSlack IDを取得する。
  → フォールバック ID: U_SELF

Step 0.5: 監視ユーザーグループを取得する。
  ~/.claude/board/council/usergroups.json を Read で読み込み、各エントリの handle を監視対象とする。
  ファイルが無い／空／読めない場合は既定の group_alpha / group_designer / group_beta を使う。

Step 1: 並行実行（Slack通知 ＋ Notion直接検索）:
  - slack_search_public_and_private: "from:Notion <@SELF_ID> after:YYYY-MM-DD" (include_bots: true, limit: 20)
  - Step 0.5 の各 handle について slack_search_public_and_private: "from:Notion <handle> after:YYYY-MM-DD" (include_bots: true, limit: 20) を1本ずつ
  - notion-search: query "@me", query_type: "internal", page_size: 10
  - notion-search: query "@me", query_type: "internal", page_size: 10
  - notion-search: query "レビュー依頼", query_type: "internal", page_size: 10

Step 2: 重複排除（page URL で）、last_edited_time が対象期間内に絞り込み

Step 3: 各ページに notion-fetch + notion-get-comments を並行実行

結果を以下のJSON配列で返す:
[{"source":"notion","source_detail":"slack_notification|notion_direct","page_id":"...","page_title":"...","page_url":"...","content_summary":"...","comments":[...],"my_mentions":[...]}]

Agent-C（Figma収集）への指示:

以下のステップに従ってFigmaのコメントを「Slack DM通知 + Figma REST API」の二経路で収集し、結果をJSON形式で返してください。取りこぼし（メンション未着・集中着信での埋没）を防ぐため、両経路を必ず実行してマージすること。
日数: <N>日間

Step 1: slack_read_channel で Figma DM 通知を取得:
  channel_id: D_FIGMA_DM, limit: 100
  → 対象期間内のメッセージに絞り込む
  → 1ページで最古が対象期間内に収まらない場合は cursor で次ページを取得し、対象期間の最古に到達するまで繰り返す

Step 1.5: Figma REST API で全コメントを補完（必須）
  a. 対象ファイルキーを決定:
     - 既定ウォッチ対象（常に取得）: Project Alpha = YOUR_FIGMA_FILE_KEY
     - Step 1 の通知本文・コメント内に生URL（figma.com/design/<KEY> または figma.com/file/<KEY>）があれば <KEY> も追加
     - ※ figma.com/email/link_redirect?… 形式はキー抽出不可。生URLかウォッチ対象で補う
  b. Bash でトークン取得: FIGMA_TOKEN=$(security find-generic-password -s "FIGMA_TOKEN" -w)
  c. Bash で各ファイルキーの全コメント取得（ファイルごと並行可）:
     curl -s -H "X-Figma-Token: $FIGMA_TOKEN" "https://api.figma.com/v1/files/<FILE_KEY>/comments"
     → レスポンス comments[]: id / message / user.handle / created_at / resolved_at / parent_id
     → 401/404/トークン無しは graceful skip（Slack DMのみで続行し、その旨を結果に注記）
  d. created_at が対象期間内のみ・自分(me/me)のコメントは除外

Step 2: 各コメントからコメント者名・ファイル名・コメント本文・Figma URLを抽出
  → Slack DM由来と REST由来をマージ・重複排除（commenter + message先頭40字 + 時刻60秒以内をキー、REST優先）
  → 各件に取得経路 via(rest|slack_dm|both) を付与

Step 3: 抽出したFigma URLに mcp__figma__get_metadata を並行実行（エラー時はスキップ）

Step 4: 各コメントの指摘種別を判定:
  BUG_REPORT / FEEDBACK / QUESTION / DIRECTION_REQUEST / APPROVAL_REQUEST / INFO
  → resolved_at が設定済み（解決済み）のコメントは ★ 相当に格下げ

Step 5: ★★★判定のコメントのみ mcp__figma__get_screenshot を実行

結果を以下のJSON配列で返す:
[{"source":"figma","via":"rest|slack_dm|both","comment_id":"...","ts":"...","commenter":"...","file_name":"...","comment_text":"...","figma_url":"...","figma_metadata":{...},"resolved":false,"type":"...","priority":"★★★|★★|★"}]

Phase 1 完了: 3エージェントの結果を待つ。失敗したエージェントは0件扱いで続行。

本文の正規化（トークン削減）: 収集結果を Phase 1.5 に渡す前に、各件の長文フィールド（Slack text・スレッド本文、Notion content_summary・コメント、Figma comment_text）を 各300字以内に要約truncate する。依頼内容・固有名詞・URL・数値・期限の手がかりは必ず残す（要約で落とさない）。スクリーンショットやメタデータは「要点1〜2文」に言語化し、画像バイナリ／巨大JSONはそのまま後段に持ち回らない。

Phase 1.5: 評議ダイジェスト生成（オーケストレーター）＝スリム化の核

Phase 2 で10ロールに渡すための圧縮ダイジェストをここで作る。生の収集データは Phase 2 に渡さない（10回フル送信を避けるのが最大のトークン削減）。

Step A — 評議対象の選別と件数上限:

• 評議対象は ★★ 以上 の件のみ。★（INFO・解決済み）は評議に回さず、Phase 4 で roles:[] の軽量 item として出力する。
• ★★以上が多い場合は priority_stars 降順で上位20件までを評議対象とする（同点は新しい ts を優先）。超過分は評議せず軽量 item 扱い。
• No Silent Caps: 「評議対象 N 件 / 軽量表示 M 件（うち上限超過 K 件）」を記録し、Phase 4 の counts と最終出力の集計行に必ず反映する。

Step B — 各評議対象の価値仮説を推定（各1文）:

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

Step C — ダイジェストを組み立てる: 評議対象の各件を次のコンパクトな形に圧縮する（生データではなくこれを Phase 2 に渡す）。

件[<id>] ★<priority_stars> <type> | <source>/<channel> | @<from>
状況: <120字以内の要約（依頼の核・固有名詞・期限の手がかりを残す）>
欲求: <○○したい> / 課題: <△△ないため>
論点: <デザイン/実装/事業など、協議で焦点になりそうな点を1〜2文>
進め方: <期限の手がかり（日付・「今週中」等） / いま自分がボールを持っているか / 初稿段階か確定段階か / 後工程（入稿・実装）の有無>
（Figmaの場合）指摘要点: <スクショ/メタから読み取った視覚上の要点1〜2文>
リンク: <主ソースURL ＋ 関係する補足URL（あれば）>

価値仮説・論点は推定であり、ロールエージェントが議論の中で修正・深化させてよい。元の生データ（全文・スレッド・巨大JSON・画像）はオーケストレーターが Phase 4 の url/links/summary 組み立て用に保持し、Phase 2 へは渡さない。

Phase 2: マルチロール協議（Sonnet × 10 並行起動）

Phase 1.5 で生成した評議ダイジェスト（★★以上・上限内の件のみ）を各ロールエージェントに渡し、同時に起動する。生の収集データ（全文・スレッド・画像・巨大JSON）は渡さない — トークン削減の核。

以下の 共通コンテキスト を各エージェントに渡す:

【評議ダイジェスト（Phase 1.5 生成・件名/状況/価値仮説/論点/リンクの圧縮版）】
<Phase 1.5 Step C のダイジェストを件ごとに貼り付け>

各ロールはこのダイジェストの価値仮説を起点として議論を展開し、必要に応じて修正・深化させてください。判断に十分な情報がダイジェストに含まれている前提で分析してください（生データの再取得は不要）。

【各件について以下を分析してください】
- 件名・送信者・内容の概要
- あなたのロールの観点からの見解（2〜3文で簡潔に）
- このロールとして重要視する判断軸
- 他のロールと対立する可能性がある点

結果は各件について次の形式で返してください:
{"id":"<source>_<ts>","role":"<ロール名>","view":"<見解>","key_concern":"<最重要判断軸>","potential_conflict":"<対立可能性>"}

Role-AD エージェントへの追加指示:

あなたはアートディレクター（グラフィックデザイナーとしてデザイン責任者から高評価）として分析します。

分析観点:
- グラフィック品質（タイポグラフィ・フォント・字間・行間の精度）
- 配色（デザイントークン準拠・コントラスト比・ブランドカラー正確性）
- レイアウト（グリッド・余白・視覚的階層・情報密度）
- グラフィック要素（アイコン品質・イラストトーン・写真クオリティ）
- ブランド一貫性（ロゴ使用・デザインシステム準拠）

🛡️ AD守備ラインの判定基準:
以下に該当する場合、必ず「HOLD_LINE: true」を含めてください:
- デザイントークンから逸脱したカラー使用
- コンポーネント仕様に反した実装要求
- グラフィック品質を犠牲にするスケジュール短縮要求
- ブランドガイドラインに反する変更要求
- 視覚的完成度を下げることを伴う機能追加要求

Role-CD エージェントへの追加指示:

あなたはクリエイティブディレクターとして分析します。

分析観点:
- クリエイティブビジョンとの整合性
- ストーリーテリング・情緒的な訴求力
- 全体的な表現の方向性・コンセプト
- プロダクトのパーソナリティとトーン

Role-Eng エージェントへの追加指示:

あなたはエンジニアとして分析します。

分析観点:
- 技術的実現性（実装可能か）
- 工数・タイムライン（何日かかるか）
- 技術的リスク（実装時の落とし穴）
- 代替案（よりシンプルに実現できる方法）
- 既存システムへの影響

Role-PdM エージェントへの追加指示:

あなたはプロダクトマネージャーとして分析します。

分析観点:
- ユーザー価値（誰にとって何が嬉しいか）
- プロダクト戦略との整合性
- 優先度（今やるべきかどうか）
- KPIへの影響
- 機能追加のトレードオフ（シンプルさ vs 機能性）

Role-CEO エージェントへの追加指示:

あなたはCEOとして分析します。

分析観点:
- 事業インパクト（売上・成長への影響）
- ブランド価値への影響
- 競合優位性
- ROI（コストに見合うか）
- ステークホルダーへの影響

Role-BrandQA エージェントへの追加指示:

あなたはブランドQA担当として分析します。

分析観点:
- ブランドガイドラインへの準拠（ロゴ使用規定・ブランドカラー・書体ルール）
- 素材のライセンス・承認状況（未承認素材の使用リスク）
- ブランドアイデンティティとの整合性（世界観・トーンの一貫性）
- 既存承認済み素材・キャンペーンとの連続性

🛡️ BrandQA守備ラインの判定基準:
以下に該当する場合、必ず「HOLD_LINE: true」を含めてください:
- ブランドガイドラインに明確に違反している表現・使用
- 未承認素材・ライセンス未確認素材の使用
- ブランドアイデンティティに矛盾するビジュアル表現

Role-DesignOps エージェントへの追加指示:

あなたはデザインOps担当として分析します。

分析観点:
- 既存デザインシステムコンポーネントの活用状況（再発明を避けられているか）
- Figmaファイル構造・命名規則・バージョン管理の準拠
- デザインシステムへの変更フィードバック（新パターンのシステム反映要否）
- デザイン〜開発のハンドオフ品質（Inspect情報・コメントの充足）
- ワークフロー・プロセスへの影響

🛡️ DesignOps守備ラインの判定基準:
以下に該当する場合、必ず「HOLD_LINE: true」を含めてください:
- デザインシステムを経由しない独自スタイルの本番投入要求
- Figmaファイル命名・構造の重大な規約逸脱でハンドオフ不能になるケース

Role-Copy エージェントへの追加指示:

あなたはコピーライターとして分析します。

分析観点:
- UXライティングの品質（明瞭さ・簡潔さ・ユーザーへの伝わりやすさ）
- ブランドボイス・トーンの一貫性（フレンドリー・プロフェッショナルなどトーン定義との整合）
- 法的・コンプライアンス上のリスク（誇大表現・禁止ワード・景品表示法など）
- ユーザーへの情報伝達の正確性（誤解を招く表現がないか）
- マイクロコピーの品質（ボタンラベル・エラーメッセージ・ヘルプテキスト）

🛡️ Copy守備ラインの判定基準:
以下に該当する場合、必ず「HOLD_LINE: true」を含めてください:
- ブランドボイス・トーンガイドラインから明確に逸脱したコピー
- 法的リスクのある表現（誇大広告・禁止ワード・誤解を招く約束）
- ユーザーに重大な誤解を与える可能性のある表現

Role-VD エージェントへの追加指示:

あなたはビジュアルデザイナーとして分析します。

分析観点:
- 視覚的階層と情報設計の整合性（重要情報が視覚的に際立っているか）
- タイポグラフィ・カラー・スペーシングの視覚的完成度
- アクセシビリティ（コントラスト比・WCAG準拠・色覚多様性への配慮）
- 全体的なビジュアルポリッシュ（仕上がりの丁寧さ・細部の精度）
- デバイス・画面サイズにおける視覚的整合性

🛡️ VD守備ラインの判定基準:
以下に該当する場合、必ず「HOLD_LINE: true」を含めてください:
- コントラスト比がWCAG AA基準（4.5:1）を下回る
- 視覚的階層の崩壊により主要コンテンツが認識困難になるケース
- アクセシビリティ基準の明確な違反

Role-Evaluator エージェントへの追加指示:

あなたは利用者の上長（評価者）の視点で分析します。
他の9ロールと違い、**案件そのものの良し悪しは評価しません**。
「me がこの案件をどう進めようとしているか」＝進め方だけを見ます。

分析観点（自分の評価軸。**利用者が `~/.claude/rules/common/evaluation-axes.md` に定義する**。
未定義なら Role-Evaluator は起動せず、この観点はスキップする）:

以下は軸の**書き方のサンプル**であって、そのまま使うものではない。
自分が実際に評価されている軸・落としたくない軸に差し替えて使う。

- F1 初期完成度: 初稿がレビュー前提の粗さになっていないか。「出してから直す」進め方になっていないか
- F2 逆算スケジュール: 期日から逆算した工程があるか。後工程（入稿・実装・レビュー待ち）のリードタイムを見込んでいるか
- F3 自己評価の精度: 役割の期待範囲内の行動を、成果・工夫として過大に扱っていないか
- F4 やりきり: 「あとはレビューで詰める」前提の受け渡しになっていないか。依頼水準を満たしてから出せているか
- F5 チームへの波及: 自分の担当範囲で止まっていないか。チームの仕組みに落とせる余地はないか

出力ルール:
- view には**該当した軸だけ**を、この案件の具体物（画面名・期日・未処理の箇所）に即して書く。一般論・精神論は書かない
- 該当が無ければ view は「特になし」とだけ返す（無理に何か指摘しない）
- key_concern には最も効いている軸の ID（F1〜F5）を入れる。該当なしなら "-"
- **「HOLD_LINE: true」は絶対に返さない**。守備ラインは品質の一線（AD/BrandQA/DesignOps/Copy/VD の領分）であり、
  進め方の警告とは別物。ここで発動させるとアプリ側の優先度スコアが全件で底上げされ、
  優先順位づけそのものが壊れる（それ自体が F2 違反になる）

Phase 2 完了: 10エージェントの結果を待つ。

Phase 3: 統合・ADスタンス確立

オーケストレーター（Sonnet）が10ロールの分析を統合して最終出力を生成する。

各件について以下を導出:

1. コンセンサス領域: 全ロールまたは過半数が合意している方向性
2. 緊張領域（⚡）: ロール間で対立している箇所と対立の本質
3. 🛡️ AD守備ライン: Role-ADが「HOLD_LINE: true」を返した場合に明示。守るべき理由とともに記載
4. 💬 ADとしての返信ドラフト: 他ロールの視点を踏まえた上で、ADの立場を明確にした返信文（Slack貼り付け用）
5. ⚖️ 評価軸アラート: Role-Evaluator が該当軸（F1〜F5）を挙げた場合に明示。守備ラインとは別枠（守備ライン＝案件品質の一線、評価軸アラート＝自分の進め方への警告）。Role-Evaluator が「特になし」を返した件には出さない

Phase 4: 構造化 JSON 書き出し（Council アプリ連携）

Phase 3 で導出した全項目を、Council デスクトップアプリ（Tauri）が読み込める構造化 JSON として書き出す。これにより、その場限りのレポートが「期限・優先度つきの編集可能な ToDo / スケジュール」として残る。

書き出し先（ディレクトリが無ければ作成する）:

• ~/.claude/board/council/latest.json — 最新。アプリが常に参照
• ~/.claude/board/council/triage-YYYY-MM-DD.json — 日付アーカイブ

出力対象:

• 評議対象（★★以上・上限内）: roles を10ロール分埋めたフル item として出力。
• 軽量 item（★ または 評議対象上限を超過した件）: roles:[]・consensus は "評議スキップ（軽量表示）"・tension/hold_line は null の軽量 item として出力（件名・summary・url・links・type・priority_stars・ball_holder・due_hint は埋める）。アプリ側で件として残るが協議メタは持たない。
• counts には Slack/Notion/Figma の収集件数を入れ、集計行に「評議 N 件 / 軽量 M 件（上限超過 K 件）」を明示する。

スキーマ（評議対象＋軽量 item の各 item を出力）:

{
  "generated_at": "ISO8601",
  "period_days": 7,
  "counts": { "slack": 0, "notion": 0, "figma": 0 },
  "items": [{
    "id": "<source>_<ts>",          // 一意ID
    "source": "slack|notion|figma",
    "channel": "...", "from": "...",
    "title": "一言で何の件か",
    "summary": "状況の要約",
    "url": "...",                    // 必須。主ソース（slack=url / notion=page_url / figma=figma_url）を転記。後方互換用。不明時のみ null
    "links": [                       // その件に関係する全リンク（複数ソース横断）。下記「links の作り方」参照。無ければ [] 可
      { "url": "...", "source": "slack|notion|figma", "label": "スレッド内Notion 等の補足（任意）" }
    ],
    "type": "DIRECTION_REQUEST|APPROVAL_REQUEST|BUG_REPORT|QUESTION|FEEDBACK|INFO",
    "priority_stars": 3,             // 1-3
    "value_hypothesis": { "desire": "欲求(HOW抜き)", "problem": "〜ないため" },
    "roles": [{ "role": "AD", "view": "...", "key_concern": "...", "hold_line": true }],
                                     // Evaluator は必ず "hold_line": false で入れる（下記注意を参照）
    "consensus": "...", "tension": "...",
    "hold_line": "守るべき理由（未発動なら null）",
    "reply_draft": "返信ドラフト全文",
    "ball_holder": "me|other",       // 自分が相手を待たせている=me
    "due_hint": "YYYY-MM-DD または null"
  }]
}

注意:

• url: 必ず元ソースへのリンクを埋める。Phase 1 の収集結果から item ごとに転記する — Slack は各メッセージの url（パーマリンク）、Notion は page_url、Figma は figma_url。アプリの詳細パネルが「ソース」テキストリンクとして表示するため、URL が取れているのに null にしないこと（取得不能な場合のみ null）。
• links: その item に関係する URL を全件入れる（/member-a-digest と同じ要領 — 1 つの ToDo が Slack/Notion/Figma を横断する想定）。アプリの詳細パネルはこの links を全件リンク表示する。組み立て方:
  • 先頭は主ソースのリンク（url と同じもの）。source にその種別を入れる。
  • Slack item: Phase 1 で取得した スレッドリプライ本文・親メッセージ内の notion.so URL を全て links に追加（収集した thread[] / notion_pages[] から転記）。source:"notion"、label に「スレッド内Notion」「仕様書」等の補足を付ける。
  • 本文・コメント内に Figma の生 URL（figma.com/design/<KEY>）があれば source:"figma" で追加。
  • 重複 URL は除く。関連リンクが主ソース1件のみなら links は主ソース1件だけ（または []）でよい。アプリは links が空なら url 単体を表示する（後方互換）。
• ball_holder: 自分が返信・対応を待たせている件は "me"、相手の対応待ちは "other"
• hold_line: いずれかのロールが HOLD_LINE: true を返した件は守るべき理由を文字列で。未発動は null。Role-Evaluator の指摘はここに入れない（アプリの優先度スコアが hold_line に +40 するため、進め方の警告で発動させると全件が高優先度になり優先順位づけが壊れる）
• roles の Role-Evaluator 要素: {"role":"Evaluator","view":"<該当軸の具体的指摘 or 特になし>","key_concern":"<F1〜F5 or ->","hold_line":false}。hold_line は常に false。アプリ側は roles[] を可変長で表示するためスキーマ変更は不要
• due_hint: 期限の手がかりがあれば ISO 日付、なければ null（アプリ側のスコアリングで期限近接度に使う）

出力フォーマット

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🎭 Council（過去 N 日間 | YYYY-MM-DD 実行）
   Slack X件 | Notion Y件 | Figma Z件
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

## 🔥 今すぐ対応（最大3件）

1. [★★★ 種別] チャンネル | @送信者 | 件名
   → 一言で: 「〜してください」
2. ...

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[1] ★★★ DESIGN_REVIEW | 📨 Slack | @member-a | #design_review | 2026-05-18 18:26
件名: Screen B リニューアル案のレビュー依頼

🎭 ロール協議:
  🎨 AD:  カラーがデザイントークン外（#2B7FFF → color.primary.500 が正しい）。Buttonコンポーネント仕様違反が2点。要修正。【守備ライン発動】
  🎬 CD:  全体のビジュアルトーンはブランドと整合。方向性OKの判断。
  ⚙️  Eng: 実装上は現状の案で問題なし。カラー修正は工数0.5日以内で対応可能。
  📊 PdM: ユーザー調査では現UIへの不満あり。早期リリースを希望。
  💼 CEO: 競合比で先行の機会。品質を保ちつつ速度優先を希望。
  🔍 BrandQA: ブランドガイドライン準拠。素材承認済み。問題なし。
  🛠️ DesignOps: カラートークン修正後、デザインシステムへのフィードバック登録を推奨。
  ✍️ Copy: ボタンラベルのトーンがやや硬い。ブランドボイスに合わせた調整を推奨。
  🖼️ VD: 修正後のcolor.primary.500はコントラスト比OK。全体ビジュアル完成度は高い。
  ⚖️ Evaluator: F1 — トークン逸脱2点が残ったままレビューに出ている。次回は共有前に /design-check を通す。

⚡ 緊張領域: ADは品質修正を要求 ↔ PdM・CEOは早期リリースを希望
✅ コンセンサス: 全体デザイン方向性はOK。細部修正のみ。
🛡️ AD守備ライン: デザイントークン逸脱・コンポーネント仕様違反は必ず修正する。これは品質基準の問題であり、リリース速度と引き換えにできない。Engが0.5日と言っているため、交渉の余地あり（スケジュール影響なし）。
⚖️ 評価軸アラート: F1 初期完成度 — 修正2点はレビュー前に自分で潰せた内容。手戻りを1往復減らせた。

💬 ADとしての返信ドラフト（Slack貼付用）:
─────────────────────────
レビューしました。全体の方向性はOKです。
リリース前に以下2点を修正してください：
① ヘッダーカラー → `color.primary.500`（デザイントークン準拠）
② ボタン角丸 → 8px（Buttonコンポーネント仕様）

Engさんに確認したところ0.5日以内で対応できるとのことなので、スケジュールには影響しない想定です。
修正後にLGTM出します。
─────────────────────────

---

[2] ★★ FEEDBACK | 📝 Notion | @member-b | Screen B リニューアル仕様書 | 2026-05-17

🎭 ロール協議:
  🎨 AD:  ...
  🎬 CD:  ...
  ⚙️  Eng: ...
  📊 PdM: ...
  💼 CEO: ...
  ⚖️ Evaluator: ...（該当軸が無ければこの行ごと省略）

⚡ 緊張領域: ...
✅ コンセンサス: ...

💬 ADとしての返信ドラフト（Notionコメント用）:
─────────────────────────
...
─────────────────────────

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
集計: 要対応 A件 / 情報共有のみ B件 | 🛡️守備ライン発動 X件 | ⚖️評価軸アラート Y件
評議: 協議 N件 / 軽量表示 M件（うち上限超過 K件）
種別: DESIGN_REVIEW P件 / APPROVAL Q件 / FEEDBACK R件 / INFO S件
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

エラーハンドリング:

• サブスキル失敗時: ⚠️ [チャンネル名]: 取得に失敗しました（スキップ） を該当セクションに表示
• 全チャンネル0件: 「過去 N 日間に対応が必要なメンション・コメントはありませんでした。」と表示

使用方法

/council        # 過去7日間（デフォルト）
/council 3d     # 過去3日間（朝のキャッチアップに最適）
/council 14d    # 過去2週間（休暇明けなど）

単体サブスキル実行（特定チャンネルのみ確認したい場合）:

/council-slack 3d      # Slackのみ
/council-notion 7d     # Notionのみ
/council-figma 3d      # Figmaのみ

自律化への拡張（慣れた後の選択肢）

現在はSKILLとして手動実行が推奨。慣れたら以下を追加できる: