spark — 小さな種を発信に育てる

設計思想

content-pipeline（まとまった素材→フルセット）と daily-content-generator（朝の棚卸し→当日全チャネル）はどちらも重量級で、「いま思いついた一言」を拾う入口がなかった。sparkはその隙間を埋める薄い前段：

• 種1個だけを扱う。フルセットは作らない（欲しくなったら content-pipeline へ手渡す）
• 種のサイズにフォーマットを合わせる（小さい種にブログを書かせない）
• 燃費目標：切り口提案まで ≤15K、生成〜保存込みで 30〜60K（Step 3.5 調査ブースト発動時のみ +20〜30K、合計 ≤90K）
• 削らないもの：アーカイブgrep・安全ゲート2本・D1/D2保存規律・草川承認

Step 1: 受付・分類

種のタイプを判定する：

タイプ	例	追加処理
①ひらめき一言	「コミバスの乗り継ぎ、アプリで見えたら便利では」	なし
②ニュースURL/記事	URL貼り付け＋「これどう思う？」	WebFetch で本文＋配信日を取得（鮮度確認。古い記事を今日のニュースとして扱わない）
③活動メモ数行	「今朝の街頭で高校生に声かけられた。通学の駐輪場の話」	なし

PDFが読めない場合は pdftotext -layout <path> - で抽出（「読めない＝ハルシネーション」と誤判定しない）。

Step 2: 接地（省略禁止）

書き始める前に、草川の過去発言との接続を必ず確認する（CLAUDE.md必須ルール）：

grep -rl "<話題ワード>" ~/.claude/agents/knowledge/kusagawa_archive/{01_council,02_publications,05_resources,06_election}/

• 話題ワードと草川独自表現（「乗って残す」等）を並列で引く
• 03_themes/*.md の該当テーマも確認
• ヒットした1〜2件だけ中身を読む（全部読まない）
• 必要時のみ WebSearch 1〜2発で事実の裏を取る。この段階では policy-researcher / kameyama-researcher 等の重い調査エージェントは呼ばない（切り口が決まる前の調査は無駄撃ちになる。深掘りは Step 3.5 で切り口確定後に穴だけ狙う）

接地の目的は2つ：(a) 切り口に「草川が語れる根拠」を持たせる、(b) 既発信との重複・誤帰属（他議員の実績を草川のものとして書く事故）を防ぐ。

Step 3: 切り口提案（確認は1回だけ）

2〜3案を AskUserQuestion で提示する。各案に必ず添える：

• 切り口の一言 — 市民生活のBefore/Afterシーン起点（事例・数字・固有名詞を冒頭に置かない＝sns-content-creator.md 📌節）
• 推奨フォーマット — 種のサイズに合わせる：
  • 小さい種 → X長文単発 or Threads 1本
  • 育つ種 → ブログnormal（800〜1500字・市民向け）＋X 1本
  • 論考級（要調査） → 「content-pipeline でフル展開」を選択肢として出す
• 過去発言との接続 — Step 2 の成果を1行で（無ければ「アーカイブ未ヒット・新規テーマ」と明示）
• 不足情報 — この切り口で書くために足りない事実を1行で（「亀山の現行データ未確認」「他自治体事例なし」等。足りていれば「接地済み・即生成可」）
• リスク初見 — 公選法・誤帰属・禁止フレーム（例：子育てDX「遅れ」、42% vs 100%の誤文脈、「次の議会で追及」型）に触れそうなら先出し

選択肢には毎回「💾 貯めておく」を含める。判断がつかない種でも捨てない。

Step 3.5: 調査ブースト（不足があるときだけ）

切り口が決まったら、生成前に不足情報を精査して埋める。切り口確定後にやるのがポイント（決まる前に調べると無駄撃ちになる）：

1. 選ばれた切り口に必要な事実を棚卸しする — 数字／制度・計画名／亀山の現状・担当課／他自治体事例／国の動向、のうちどれが未確認か
2. 不足の重さで埋め方を変える：

不足レベル	埋め方	燃費
軽微（1〜2点の単発事実）	自前で WebSearch/WebFetch（公式サイト直当て）	+数K
亀山側の構造的不足（計画・議事録・担当課・市の現状）	kameyama-researcher を1回だけ呼ぶ。D5厳守：「依頼スコープに直接答える資料に限定・tool_uses 30回以内」を指示文に明記	+20〜30K
国動向・他自治体事例の構造的不足	policy-researcher を1回だけ呼ぶ（同じくD5厳守）	+20〜30K
両方が構造的に不足（＝論考級だった）	content-pipeline へのフル委譲を再提案（sparkで抱え込まない）	—

3. 調査結果は事実パック（出典URL・数字・固有名詞をコピペで列挙した完成形）に整えて Step 4 の委譲プロンプトへそのまま渡す。生成エージェントに再調査させない（lean原則：完成形渡し）
4. 調査しても埋まらなかった穴は、生成物でその論点に踏み込まない or「市の公表資料では確認できていない」と正直に書く。推測で埋めない（架空・ハルシネーション禁止）

Step 4: 生成（選んだ分だけ）

選ばれた切り口＋フォーマットで既存エージェントに委譲する：

フォーマット	委譲先	指示に含めること
SNS単発	sns-content-creator	該当プラットフォームのみ生成（7PF全部は作らない）。X=長文可・1ツイート1メッセージ・URLはリプライ欄・#草川たくや #ええやん亀山＋テーマタグ2〜3
ブログ市民向け	blog-writer-normal	冒頭「こんにちは、亀山市議会議員の草川たくやです。」・タイトル50字以内・定型フッター込み
ブログ深掘り	blog-writer	同上＋最先端事例スキャン要否を先に判断（AI/DX系は必須）

共通の縛り（委譲プロンプトに明記）：絵文字なし・他議員氏名なし・架空エピソード禁止・抽象比喩/禁止フレーズ集（「届かないを終わらせる」等）回避・voice-dna.md 照合。

Step 5: 安全ゲート→保存（skip禁止）

1. 元版（ブログ or 最初の1原稿）は content-fact-checker → content-risk-reviewer の2段。指示文に ledger: ~/outputs/<日付>_<テーマ>/_ledger.json を1行入れる。PF別の派生版は content-gate-lite 派生モード1回（mode: derivative＋同じ ledger:）で束ねる。HIGH以上は草川に問いかけ、CRITICAL は即停止
2. 生成物を Obsidian vault に一字一句そのまま Write（D1。フッター省略禁止）→ bash ~/.claude/scripts/obs_open.sh <パス> で開く。置き場＝ブログ ~/Documents/ObsidianVault/50_発信/<日付>_<テーマ>/<日付>_<テーマ>_v1.md／SNS 50_発信/<日付>_<テーマ>/<日付>_<テーマ>_SNS7PF_v1.md／ショート動画 50_発信/<日付>_<テーマ>/<日付>_<テーマ>_ショート動画台本_v1.md（ファイル名の「SNS」「ショート動画」は種別判定に使うので外さない。drafts/ はObsidianで読めない＝OPERATIONS.md【C】D7）
3. 指摘の反映と草川承認を済ませてから1回で Notion 保存（D2。「とりあえず保存→後で上書き」禁止）：
   • ブログ → ブログDB（notion-saver 経由・保存後 fetch で漢字化け検証）
   • SNS → 📣SNS投稿管理DB（ds 1bd98deb-）
4. 当日の nichijo 日次ログへ🔖台帳1行を追記：

   🔖 HH:MM 〈種の要約15字以内〉→発信化 → <mention-page url="...">保存先ページ名</mention-page>

写真つきの種（photo-post連携・2026-07-05追加）

種に写真（ファイルパス・添付）が一緒に投入されていたら、Step 5 の保存完了後に「📸 photo-post で投稿画像＋ショート動画も作る？」を選択肢として提示する。YESなら photo-post スキルを PAIRモード（生成済み投稿文を渡す）で起動する——文の再生成はさせず、コピー抽出→画像合成→動画→安全ゲート（画像・動画分のみ）に直行。

ストック分岐（「貯めて」「ストックして」）

Step 2 まで実施してから、📣SNS投稿管理DB（ds 1bd98deb-）に新規ページを作る：

• タイトル: 💡<種の要約>
• ステータス: 未着手
• 本文: 種の原文＋Step 2 の接地結果（アーカイブヒット・関連過去発言の要約）＋切り口の芽＋不足情報リスト（後日展開するとき、そのまま Step 3.5 の調査計画になる）

→ daily-content-generator の朝の棚卸しが💡ネタを候補として自動的に拾う（ネタ帳DBは新設しない）。🔖台帳1行も追記して終了。

やらないこと

• 7PF一括生成・セリフ型ショート動画・印刷物（それぞれ sns-content-creator フル / short-video-create / print系 の領分）。ただし写真つきの種の投稿画像・写真動画化は photo-post に橋渡しする（上記連携節）
• 一般質問ネタとしての深掘り（政策の種と判明したら「📝一般質問ネタDB or 🎯政策候補DB に振り分ける？」と smart-intake の判定ツリー#5 へ橋渡し）
• 保存だけしたい入力の処理（smart-intake の領分）

---

📌 DB統一override（2026-07-05・本文の旧記述より優先）

• 🎯政策候補DB（ds 6f1895ac- / page b9f8d42a）は凍結済み・新規書込禁止。🗄️旧アーカイブ内に参照専用で保管（過去分の参照・引用はOK）。
• 政策ネタ・一般質問ネタの登録/更新はすべて「🎯政策・質問ネタDB（統一パイプライン）」1本：data_source 42716725-fece-497f-9782-705076539de4 / page cb47d25e30b14b61b39f56254bf9432a（🎯政策・質問ハブ=34bcf503-819e配下）。
• 統一DBの使い方：状況=収集→未整理→調査中→質問案→提出/通告→実施→完了／時間軸=議会直近（3か月以内の議会論点）・中長期（旧政策候補相当）・観察／ネタ元に「市政報告会・政策スキャン・AIインタビュー・地域訪問」追加済み。
• 本文中の「政策候補DBへ保存」は「統一DBに時間軸=中長期で保存」と読み替える。凍結DBの案件を再開する時は、その1件だけ統一DBへ昇格させる。