shisei-houkokukai スキル

市政報告会を「企画相談→案内文兼レポート→スライド→連動解説→前夜チェック」の5ステージでプロデュースする。1回の起動で1ステージだけを丁寧に進め、各ステージ出口で草川承認を取る。スピード重視の一括生成は既存の仕組みで足りているため、本スキルは地域ごとに毎回相談しながら作るスタイルを体現する。

設計の背景・判断根拠は設計書 /Users/kusakawatakuya/.claude/skills/shisei-houkokukai/design/2026-07-04-shisei-houkokukai-design.md（§1〜§9）。本ファイルは実行手順に徹する。

---

共通ルール（全ステージ共通・起動直後に必ず実行）

起動時の状態復元

1. 地区名・開催日が特定できたら、まず正本の状態ファイルを探して読む: ~/outputs/houkokukai/<YYYY-MM-DD>_<地区>/_status.json。あれば各ステージの状態（未着手/進行中/完了）を復元し、「いまStage◯まで完了。次はStage◯です」と1文で提示する。無ければ新規開催として扱う（Stage1で作成）。
2. ステージ名を言わない起動（「〇〇の報告会よろしく」等）は、_status.json の進捗を見て次の未完了ステージを提案し確認を取る。勝手に走り出さない。
3. 短縮経路の自動提案: 開催日が判明した時点で 残り日数 = 開催日 - 今日。14日未満なら短縮経路（Stage1簡易版→Stage3→Stage4）を提案する（本ファイル末尾「短縮経路」参照）。フル経路とどちらで進めるか草川に確認する。

進捗の正本 = ローカル _status.json／Notionはミラー

• 正本: ~/outputs/houkokukai/<YYYY-MM-DD>_<地区>/_status.json（機械可読）。各ステージの完了時に必ず更新する。書き込み失敗が即発覚するようローカルJSONを正本にする。
• Notionミラーはベストエフォート: 🎤市政報告会DB（data_source df08b5ea-f5ff-4022-afe2-c8073fbe341a）の該当ページ（無ければStage1で新規作成）に「## 準備ステージ進捗」を各ステージ完了時に反映。ミラー書き込みが失敗しても工程は止めない（正本はJSON）。Notion編集は update_content の罠（複数セクション一括置換を避けfetch検証を挟む・固有名詞はコピペ）に従う。

_status.json スキーマ（このまま生成・不明値は空文字/空配列で初期化）:

{
  "event": {"district": "", "venue": "", "date": "YYYY-MM-DD", "slot_minutes": 60},
  "schedule": {"distribution_deadline": "", "stage2_deadline": "", "stage3_target": "",
               "stage4_target": "", "stage5_date": ""},
  "stages": {
    "stage1": {"status": "todo", "completed_at": "", "artifacts": [], "themes": []},
    "stage2": {"status": "todo", "completed_at": "", "artifacts": []},
    "stage3": {"status": "todo", "completed_at": "", "artifacts": []},
    "stage4": {"status": "todo", "completed_at": "", "artifacts": []},
    "stage5": {"status": "todo", "completed_at": "", "artifacts": []}
  },
  "notion_page_url": ""
}

• status は todo / doing / done の3値。artifacts は生成物の絶対パス配列。stage1.themes は確定テーマ配列。

出力先（絶対パス・cwd依存禁止）

~/outputs/houkokukai/<YYYY-MM-DD>_<地区>/
  _status.json  進捗の正本
  01_kikaku/    企画シート.md（地区カルテ＋確定テーマ＋構成骨子＋演出配置案）
  02_report/    案内文兼レポート（HTML/CSS・PDF・assets/）
  03_slides/    slides.html／<地区>市政報告会_<日付>.pdf／assets/／_review/
  04_kaisetsu/  kaisetsu.html／解説_<地区>_<日付>.pdf（スマホ縦）
  05_zenya/     前夜チェック.md／想定QA.md

• 完成PDF（レポート・スライド）の Driveミラー格納（ZZ_市政報告レポート/ 慣行）は、Stage2/Stage3完了時に草川へ1回確認してから置く。勝手に置かない。

テンプレ血統デッキ（参照専用・移動/削除禁止）

~/.claude/skills/slide-deck-prep/output/（御幸2026-05-30／小下05-31／木下06-13／太岡寺06-25／城東07-04）はテンプレ血統。CSS骨格の複製元として参照するのみ。移動・削除しない。直近＝城東版を第一参照にする。

モデル方針・全ステージ共通の禁止

• 品質最重視のため Stage3（スライド）・Stage4（解説）はメインループのモデルで実行（省コスト用の格下げをしない）。
• 全ステージ共通のハードルール: 架空エピソード禁止／他議員氏名を対外発信物に載せない（汎用表記に変換）／議事録引用は草川発言＋市答弁ペアのみ／抽象・詩的比喩禁止／絵文字を装飾に使わない（Notion DB固有名詞内の絵文字はそのまま可）。

---

Stage1 企画相談

目的: いきなり作らず、地区カルテ→テーマ相談→構成骨子確定まで。「相談しながら」の起点。このステージでは制作物を作らない。

構造 = 二段化: 「全部調べてから聞く」ではなく「当たりをつけてから深く調べる」。相談前に全サブエージェントを並列起動しない（カルテが情報の山になり相談が埋もれ、トークンも浪費するため禁止）。

第1段: 軽量パス（相談の材料づくり・サブエージェントは scout 1本のみ）

1. 🎤市政報告会DB（df08b5ea-f5ff-4022-afe2-c8073fbe341a）: 同地区の過去開催ページから「前回の宿題とその後」＋前回の演出の効き（参加者数・質問件数・反応メモ＝Stage5の還流データ）を抽出。
2. 🏘️自治会別訪問管理DB（data_source 996b1d15-2454-4667-9702-05d6d0faa75c・地区特性メモ含む）・📝市民意見リスト（c2c34bd8-）: 地区の生の声を抽出。
3. district-issue-scout を起動（軽量パス唯一のサブエージェント）: 「議事録・市資料から〈地区〉×市政テーママップ＋簡易ハザードフラグを返す」。従来の手動アーカイブgrep（地区名＋草川語彙並列・地区版ニュース有無確認）はscout の内部手順に吸収されているので、スキル本体では手動grepを実行しない。依頼文にスコープ限定（この地区の供給側テーマに直接答える資料に限定・tool_uses 30回以内目安）を含める。
4. 直近の市政動向: 直近議会の議案・現況報告・📰ニュースDB を確認。

→ 続けて下記「地区解像度ヒアリング」→ テーマ候補を草川に提示して一次相談（興味の当たりをつける）。

地区解像度ヒアリング（テーマ相談の前に必ず挟む）

データで埋まらない解像度は草川に尋ねて埋める。

• 原則1: 調べて分かることは聞かない。軽量パス1〜4を先に済ませ、カルテのドラフトを「ここまで把握しています」と提示した上で、空欄の項目だけを問いにする。問いは汎用フォームでなく収集結果から生成した具体形にする（例:「みずきが丘は新興住宅地、菅内側は旧集落と把握していますが、当日会場に来るのはどちら寄りの顔ぶれですか？」）。
• AskUserQuestion を1回だけ・最大4問にまとめる。定番の確認観点（カルテで埋まらなければ聞く）:
  1. 地区内のサブ地域構成（字名・団地名・旧集落の別、新旧住民ミックス、世帯層の偏り）
  2. 当日の顔ぶれ（どのサブ地域から来るか・年齢層・人数感・政治的関心度・キーパーソン）
  3. 地元の空気・最近の出来事（データに出ない温度感＝祭り・工事・事故・自治会内の話題）
  4. 触れ方に注意がいる話題（地区内で意見が割れている件・センシティブな経緯）
• 原則2: 一度聞いたことは二度聞かない。回答は企画シートに反映すると同時に、🏘️自治会別訪問管理DB（data_source 996b1d15-2454-4667-9702-05d6d0faa75c）の該当ページに「地区特性メモ」として追記蓄積する。次回同地区開催時はこれを「前回把握済みの特性」として提示→差分だけ確認する。
• 回答が得られない項目は企画シートに「(未確認)」と明示し、推測で埋めない。

承認ゲート①: テーマ価値批評（一次相談の前に実行）

• audience-experience-reviewer のテーマ価値モードを起動。軽量パスで出た候補テーマ一覧に「この地区の住民が平日夜／休日の60分を割く価値があるか」「聞いた人の行動が変わり得るか」「一般論に落ちていないか」の3観点で序列＋ボツ推奨＋磨き方を返させる（深掘りパスの投入先を絞る判断材料を兼ねる）。
• 批評を反映した候補で一次相談（草川に提示し、興味の当たりをつける）。

第2段: 深掘りパス（草川が採用に傾いたテーマのみに投入）

• citizen-voice-analyst: 採用候補テーマ×この地区の声のボリュームゾーン・隠れた痛み。依頼文はテーマ＋地区限定・tool_uses上限を明記（D5準拠）。
• policy-archive-miner: 採用候補テーマごとの草川の過去発言・実績との連続性。
• district-hazard-analyst: 防災が柱候補になった場合／scoutの簡易ハザードフラグが立った場合のみフル起動。地区のハザードマップを実地読解し「地区防災カルテ（該当ハザード＋根拠マップ出典／突合で見つかった問題点／提案の種／スライド用の図表指示）」を返させる。数値・区域・避難所名は fact-checker 必須＋出典明記を依頼文に含める。
• 深掘り結果で候補の解像度を上げ、二次相談（採否・順番の確定）→確定へ。

出力 = 企画シート（01_kikaku/企画シート.md）

以下を含める:

• 地区カルテ要約: 固有フック一覧（道路名・学校名・過去の声・前回宿題）＋地区解像度ヒアリングの結果（サブ地域構成・当日の顔ぶれ・注意話題。未確認項目は明示）。
• テーマ候補3〜5本: 各テーマに「なぜこの地区でこれか」1行＋想定山場。二次相談で確定した採否・順番を反映。
• 推奨構成骨子: 柱構成・枚数感・時間配分。
• 演出配置案（references/engagement.md の基準を当てて決める。着手前にこのファイルをReadする）: どの柱の頭にクイズを置くか／どの固有名詞・地図・Before/Afterで自分ごと化するか／締めの「未来の分岐＋行動CTA」を何にするか。
• 山場数字の裏取り: クイズの答え・山場で使う数字はこの時点で content-fact-checker に通して確定させる（構成の土台になる数字が後で崩れるとスライド作り直しになるため。Stage3のfact-checkは軽い再照合に格下げされる）。
• 開催情報: 日時・会場・時間枠・想定聴衆。不明項目は草川に確認。
• 逆算スケジュール: 開催日から逆算し ｛案内配布締切（回覧板・ポスティングのリードタイム2〜4週間を考慮）→Stage2締切→Stage3/4推奨日→Stage5前夜チェック日｝ を確定して _status.json の schedule に記録。

承認ゲート②: 確定とスケジュール登録

1. 二次相談で確定したテーマ・順番を企画シートに反映。
2. 逆算スケジュールを確定し _status.json に記録。
3. Todoistへ期限付きタスク登録を提案（Stage2/3/4/5の各推奨日）。登録は python3 ~/.claude/scripts/todoist/td.py add "内容" --due <日付> --project 議員活動 で、草川承認後にのみ実行する。承認前に勝手に登録しない。
   • 🗓 期限つきで登録する場合は task-add の突合手順を通す（想定所要を1hセッション換算→カレンダー突合→✅/⚠️/🚫判定→承認）。突合なしの td.py add --due、Todoist MCP update-tasks での期限後付け、reschedule-tasks での明後日以降への期限設定は PreToolUse hook が deny する。今日・明日への移動（朝の繰越・即日対応）はゲート対象外。期限なしの登録はこれまで通り。
4. Notionミラー: 🎤市政報告会DBに該当ページが無ければStage1で新規作成（開催日・開催地区・開催自治会relation・会場・形態を設定）し、「## 準備ステージ進捗」を反映（ベストエフォート）。notion_page_url を _status.json に記録。
5. _status.json の stage1.status = "done"・completed_at・artifacts（企画シートのパス）・themes（確定テーマ）を更新して終了。

---

Stage2 案内文兼レポート

⚠️ 2026-08-10〜: 実物の制作は chiku-report スキルへ委譲する。
Stage2は「薄いラッパー」だったため、北東地区版で事故が集中した（隣地区版と真逆の記述／scoutの誤った地区比定／自己実績の誤帰属／約束型表現／図表不足／横幅の破綻／QRのデコード不能）。
本ステージに来たら、まず chiku-report を起動すること。 以下はStage2としての位置づけの記述にとどめる。

目的: 開催案内（日時・会場・地図・QR）＋ミニ市政報告を兼ねたA4印刷物。

1. 企画シート（01_kikaku/企画シート.md）と _status.json を読む。
2. 実装は既存印刷フローに委譲: print-designer → print-layout-architect → natural-design-reviewer（HTML/CSS→PDF、レイアウト作り込み、物理破綻チェックの反復）。
3. スキル固有の責務は2点のみ:
   • 企画シートとのテーマ整合: 確定テーマから予告に載せるものを選ぶ。
   • 期待醸成フック: 当日クイズの予告（「〇〇、いくらか知っていますか？答えは当日」型）等、報告会に来る動機を作る要素を1つ以上入れる。
4. 品質基準: デザイン品質基準（中庄夏祭りポスター2026水準）＋市政報告レポート印刷物チェックリスト＋絵文字なし。他議員氏名を載せない。
5. 安全2ゲート必須: content-fact-checker（数値・固有名詞・法令・統計を一次情報まで検証）→ content-risk-reviewer（8軸スキャン）。HIGH以上は草川にASK_USER、CRITICALは即停止して通知。
6. PDF生成後 open <絶対パス> を即実行してプレビュー。
7. 草川承認 → 02_report/ へ確定保存。Driveミラー（ZZ_市政報告レポート/）格納の可否を草川に1回確認してから置く。
8. _status.json の stage2 を done 更新＋Notionミラー（ベストエフォート）。

---

Stage3 スライド（最重視）

目的: 確定ルール（2026-07-05草川決定・本スキルが正本）通り HTML/CSS→PDF で、演出ドクトリンを組み込んだデッキを作る。

着手前に必ず ~/.claude/skills/shisei-houkokukai/references/engagement.md を Read する（参加型／自分ごと化／未来提示の3軸パターン・密度基準・禁止事項をここから当てる）。

制作規格（既存確定分・変更なし）

• 16:9（13.333×7.5in）／草川カラー（--lime:#c7ff4a / --green-deep:#0f3d27 / --green:#1f5a3a / --cream:#f3efe4）。
• topbar lime帯・cover濃緑左＋顔写真右＋namechip・foot「草川たくや 市政報告会＠<地区>」。
• テンプレ血統デッキ（直近＝城東版）のCSS骨格を複製→地区化。
• 素材: 地区の市政報告レポート印刷物フォルダ＋過去デッキ assets から sips -Z 1500 で最適化コピー。EXIF正規化（PIL ImageOps.exif_transpose＋EXIF strip）。

参照と5軸目標（着手前・skip禁止）

（2026-09-15 草川指示で追加・正本＝memory feedback_design_reference_library_first）

テンプレ血統デッキはCSS骨格の複製元であって造形の参照ではない（草川の自作物＝参照の質ゲート外）。骨格だけで組むと、破綻はしないが帯と箇条書きだけのデッキが返る。

1. ~/.claude/agents/knowledge/design_system/references/_INDEX.md から16:9スライドの参照を1本だけ選び、その画像を自分でReadする（カルテを読むだけで進まない）。
2. 判型フォルダの _karte.md から5軸目標を数値で決め、企画シートの構成骨子の下に書き出す — ①級数ジャンプ率 ○倍（最大見出し÷本文）②色数 ○色と役割 ③図形語彙（斜め／円・円形抜き／重ね／ピル・角丸／地紋／表組み／写真ブリード から参照が使うもの）④写真・図版占有率 ○% ⑤イラスト・アイコン ○点。slides.html はこの数値を目標に書く。
3. 参照未整備時（2026-09-15時点で該当＝references/ に16:9スライドの判型フォルダが無い）: 「参照未整備」と草川に1行で明示し、作る前に design-inspiration-researcher を起動して、プロ制作の16:9スライド（省庁・自治体の説明資料、公的機関・企業の公開デッキ等。議員の自作スライドは不可）を1〜3本収集→ references/slide_16x9/ へ画像＋_karte.md（5軸採寸）を回収し _INDEX.md に行を足してから入る。依頼文に tool_uses 上限を明記。
   • thumbnail/（同じ16:9）は代用しない。1メッセージの掴み画像で、情報を載せるスライドとは判型が別（memory feedback_reference_must_match_format）。
   • 短縮経路で収集の時間が取れない場合のみ、草川に「参照なしで作る」と明示して承認を取り、採点（品質ループ3）は「参照未整備のため実施不可」と記録する。黙って飛ばさない。

演出ドクトリンの適用（engagement.md に従う）

• 参加型: クイズは「問題スライド→答えスライド」の2枚ペア。挙手アンケートの進行キューはノート側に持つ。密度は30分枠で2回以上・60分枠で3〜4回を出発点とし、企画シートの「当日の顔ぶれ」に応じて増減（機械適用禁止）。
• 自分ごと化: 各柱に地区固有スライド1枚以上（道路名・学校名・地図・Before/After）。見出しは「皆さんの〜」「この地区の〜」主語。一般論スライドの直後に必ず「では<地区>では？」の接続を入れる。素材は企画シートの地区カルテから拾い、Stage3で調べ直さない。
• 未来提示: 締めブロックに分岐スライド（「このままだと…／こうすれば…」2列対比）。最終CTAは行動メニュー型（声を寄せる＝ご意見箱・公式LINE／AIインタビュー参加 https://depth-interview-kusagawa.vercel.app/／アンケート回答／次回参加）を最低2種以上。単一CTAで終わらせない。

品質ループ（順番厳守・構成の直しをデザイン磨きの前に済ませる）

1. slides.html → PDF化（Chrome headless）→ open でプレビュー。

2. audience-experience-reviewer 聴衆冷読みモード（内容・構成レビュー）: 聴衆ペルソナ（企画シートの「当日の顔ぶれ」から毎回生成。顔ぶれ情報が無い場合のみ子育て世代・高齢者・政治無関心層をフォールバック既定値に）でデッキを通し読みし、飽きカーブ・脱落ポイント・置いていかれる用語・クイズの実効性・自分ごと化度を「スライドN単位の外科的TODO」で指摘 → 構成レベルの直しをここで済ませる。

3. 模写採点 ★ハードゲート（2026-09-15 草川指示で追加・正本＝memory feedback_design_reference_library_first・skip禁止）: 構成が固まった後・物理破綻チェックの前に置く（造形の差し戻しは再レンダを伴うので、物理破綻チェックは造形確定後に1回で済ませる）。表紙・柱の山場1枚・数字/図解スライド1枚・分岐スライドの代表3〜4枚をPNG化し、参照画像と両方を自分でReadして5軸を数値比較する（サブagentへ委譲しない）。

   軸	可	不可（slides.html へ差し戻し）
   ① 級数ジャンプ率	参照の70%以上	参照6倍に対し出力2倍
   ② 色数	参照−1色まで	参照4色に対し出力2色
   ③ 図形語彙	参照の語彙の半分以上	topbar帯と箇条書きだけ
   ④ 写真・図版占有率	参照の70%以上	参照40%に対し出力10%
   ⑤ イラスト・アイコン	参照が使うなら必ず使う	素材が無いからゼロ、は不可

   1枚ごとに5軸中4軸で「可」以上が合格。1枚でも不合格なら差し戻し→再レンダ→再採点。採点5行（×枚数）をチャットに出し、素材の使い残し（地区フォルダの写真枚数 vs デッキで使った枚数）も1行で数える。草川カラー・絵文字なし・人物を描かない等の既存規格は採点で上書きしない。

4. natural-design-reviewer 反復（PNG化・物理破綻チェック）。2回目以降は前回未指摘の新規問題のみ。破綻ゼロは合格ではない（3を通っていること）。

5. content-fact-checker 軽い再照合（山場数字はStage1で裏取り済み＝ここでは新規追加分と直近議会の議決状況など鮮度もののみ）。

6. content-risk-reviewer（8軸。2026-10-25市議選が近づくほど事前運動リスクを厳格に見る）。HIGH以上は草川にASK_USER、CRITICALは即停止。

7. 草川最終承認 → 各スライドに data-id（例: s-taiyoko-quiz）を付与してスライドIDを凍結する。Stage4はこのIDに紐付く（連番でなくIDなので後の挿入・差し替えに耐える）。

8. 03_slides/ へ確定保存。Driveミラー（ZZ_市政報告レポート/）格納の可否を草川に1回確認してから置く。_status.json の stage3 を done 更新＋Notionミラー。

---

Stage4 連動解説（ノート＋山場フル台本）

目的: 確定スライドに1:1連動した「当日の語り」の設計。

着手前に必ず ~/.claude/skills/shisei-houkokukai/references/kaisetsu_format.md を Read する（カード class 契約 card-note/card-yamaba/card-time・data-id 必須・390px縦PDFの /Count 1 探索手順をここから当てる）。演出キュー・CTAメニューは references/engagement.md、山場の語り技法は community-rally-speaker を参照craftにする。

生成ルール

1. スライドIDロック: Stage3承認後の slides.html の data-id を正とし、解説カードはID単位で1:1対応（表示上は現在の通し番号も併記）。連番でなくID紐付けなので、スライドの挿入・差し替えが起きても該当カードだけ再生成すれば済む（Stage5の差分再生成の前提）。
2. 全スライド共通のノート項目: 話す骨子（3行以内）／時間目安（累積分表示）／問いかけ・挙手キュー／専門用語の平易言い換え（プレイブックD-3辞書を適用）。カード種別は card-note（通常）。
3. 山場のみフル台本（企画シートの演出配置案で決めた箇所＝掴み・各柱のクイズ・分岐スライド・締めCTA。カード種別 card-yamaba）:
   • クイズの回し方（問いを投げてから答えを言うまでの間の取り方・会場の答えの拾い方・外れたときの受け）を読み上げ文そのままで書く。
   • community-rally-speaker の技法を参照craftとして適用（掴み30秒→柱→結び1分のアジ構造・生活者の言葉・曖昧な敵の使い方）。
   • 語りは voice-dna 照合。おうむ返し・AI定型句を排除。
4. 時間チェックポイントは card-time（濃緑カード・押している場合の削り所を書く）。
5. 冒頭挨拶はプレイブックD-1テンプレート準拠。
6. audience-experience-reviewer 聴衆冷読みモード（台本込み通し）: スライド＋解説をセットで疑似聴講し、語りレベルの飽き・置いてけぼり・行動意欲を最終チェック（ペルソナは企画シートの顔ぶれから生成）。
7. 安全2ゲート: content-fact-checker（台本の数字がスライドと同じか照合）→ content-risk-reviewer（口頭表現の公選法・品位）。HIGH以上はASK_USER、CRITICALは即停止。

納品形式 = スマホ縦スクロールPDF

• kaisetsu_format.md の手順に従い 幅390px・1ページ縦長・カード型・絵文字なし。+200px は探索の出発点であって固定値ではない——毎回スクショ実測→/Count 1 の高さを下から探索して確定する。
• カード配色: 通常ノート＝クリーム地（card-note）、山場台本＝lime帯付き強調（card-yamaba）、時間チェックポイント＝濃緑（card-time）。
• 生成後 open <確定PDF絶対パス> でプレビュー → 草川承認 → 04_kaisetsu/ へ確定保存。_status.json の stage4 を done 更新＋Notionミラー。

---

Stage5 前夜チェック

目的: 本番前日の総点検。軽量・1パス。

1. 直前差分スキャン: スライド確定後の市政の動き（議決結果・報道・市発表）を WebFetch／📰ニュースDB で確認し、更新すべきスライド・解説カードを列挙（「太陽光議決状況が未確認のまま本番」型事故の防止）。修正が必要な場合は該当スライドの data-id 単位で差し替え → 対応する解説カードのみ再生成（全体再生成は前夜にやらない。kaisetsu_format.md §3 の差分再生成手順に従い /Count 1 を再探索）。
2. 想定Q&A: 地区の声＋直近議会から出そうな質問トップ5〜8と返しの骨子を counter-argument-simulator の軽量版で作る（フル議場戦闘マニュアルは作らない）。05_zenya/想定QA.md に保存。
3. 進行チェックリスト: タイムテーブル（開始〜質疑〜締めの分刻み）／持ち物（PC・プロジェクター・配布物・名簿※個人情報区画ルールに従い名簿本体は隔離）／会場設営メモ。05_zenya/前夜チェック.md に保存。
4. 終了後の締めリマインド: 「記録：〇〇報告会で△△の声」トリガーの案内を1行添える（既存の声記録ルール＝OPERATIONS.md【A】に接続。本スキルでは声記録を再実装しない）。あわせて演出の効きメモ（クイズは答えが出たか・どこで空気が緩んだか・参加者数／質問件数）を🎤市政報告会DBに残すよう促す——これが次回Stage1軽量パスの「前回の演出の効き」還流データになる。実地とドクトリンの乖離が大きければ references/engagement.md の更新を提案する（ドクトリンを初版のまま腐らせない）。
5. 出力は 05_zenya/ に md 保存＋チャット表示。希望があればスマホ縦PDF化も可。_status.json の stage5 を done 更新＋Notionミラー。

---

短縮経路（急な開催向け・残り日数 14日未満）

5ステージをフルで回す余裕がない場合の公式ルート。起動時に開催日を確認した時点で残り日数から自動提案する。

1. Stage1 簡易版: 軽量パス（🎤DB／🏘️DB／📝市民意見リスト／district-issue-scout／直近市政動向）＋地区解像度ヒアリング＋テーマ即決（audience-experience-reviewer テーマ価値モードは通すが、深掘りパスは省略可）。山場数字の content-fact-checker 裏取りは省略しない。企画シート最小版と _status.json・逆算スケジュールは作る。
2. Stage3（スライド）: 通常手順。参照と5軸目標・品質ループは省略しない（聴衆冷読み→模写採点→物理破綻→軽い再照合fact-check→risk-review→承認→data-id凍結）。
3. Stage4（連動解説）: 通常手順。
4. Stage2 は既存チラシ・口頭案内で代替（新規作成しない）。
5. Stage5 は当日朝に最小版（直前差分＋タイムテーブルのみ）。

短縮経路でも安全2ゲート（content-fact-checker → content-risk-reviewer）・主担当エージェント・草川承認ステップは削らない。