実務の意思決定・知見から外部発信（LT・ブログ・登壇）のネタを発掘し、発信可能な形に再構成するスキル。「ネタから始める」スキル（発表構成がメインなら lt-outline-builder を使う）。「発信ネタがない」「ADR を LT に使いたい」「ブログ構成が決まらない」「社内情報の切り分けが難しい」「来月の LT 会でネタがほしい」「会話から発信ネタを抽出したい」「ネタはあるが形にするコストが高い」「技術ブランディングを積み上げたい」「書こうと思ってたけど構成で止まってる」「ADR をそのまま発信できないか」「発信するか迷ってる」「ネタ帳を作りたい」「さっきの話って記事にできる？」「この判断ってブログネタになる？」「これ発信していい内容？」といった場面で必ずこのスキルを使用する。ADR Capture との連携でより精度が上がるが、単体でも機能する。

Content Seed — 実務知見からの発信ネタ発掘・整形

実務の意思決定・知見の中に眠っている「発信価値のある情報」を発掘し、LT・ブログ・Twitter / X スレッドなどチャネルに合わせた構成案・下書きとして出力する。

いつ使うか

「ネタがない」ではなく「ネタが見つかっていない」状態のとき
ADR や設計判断を外部発信に転用したいとき（「なぜ A ではなく B にしたか」は強いコンテンツになる）
ブログを書こうとして白紙で止まっているとき
社内情報をどこまで出せるか判断に迷っているとき
会話の中で「これ発信できそうだな」と思ったネタを形にしたいとき

このスキルがやらないこと

完成原稿の自動生成（構成案・下書きまで。肉付け・ファクトチェック・トーン調整はユーザーが担う）
社内情報の完全自動除去（抽象化案を提示するが、最終確認はユーザーに委ねる）
ネタ帳ファイルの自動更新（Markdown テキストを出力するのみ。保存はユーザーが行う）
実際の発信の代行（投稿・公開はユーザーが行う）
ADR の新規作成（adr-capture スキルの責務）
ゼロからの発表構成設計（ネタが決まった後の詳細な構成案が必要なら lt-outline-builder を使う）

推奨モデル

フェーズ	推奨モデル	理由
ネタの発掘・スコアリング	Opus	「再現性」「意外性」「独自性」の判断は深い推論が必要
社内情報の検出・抽象化	Sonnet	パターンマッチと定型変換が中心
チャネル別の構成整形	Sonnet	テンプレートに沿った構造化出力が中心

一気通貫で実行する場合は Opus で通すのが安全。

入力パターンと対応フロー

パターン	判定	フロー
ADR カタログ	ディレクトリパスまたは ADR テキストが渡された	ネタ発掘フロー（スキャン→スコアリング→提示）
会話ベース	「最近〇〇やって…」「壁打ちしたい」	会話からのネタ発掘フロー
ネタ指定	「このネタをブログにしたい」「LT 構成を作って」	直接チャネル整形フロー
ネタ帳管理	「ネタ帳を更新して」「一覧を出して」	ネタ帳管理フロー

フロー別エントリーポイント

パターン	Stage 1	Stage 2	Stage 3
ADR カタログ	スキャン→スコアリング	社内情報チェック（条件次第）	チャネル選択後に整形
会話ベース	発掘のアンテナで抽出	社内情報チェック（条件次第）	チャネル選択後に整形
ネタ指定	スキップ（ネタは確定済み）	社内情報チェック（条件次第）	チャネル指定済みなら即整形、未指定なら確認
ネタ帳管理	スキップ	スキップ	スキップ（管理操作のみ）

Stage 1: ネタの発掘

ADR カタログからの発掘

ADR が渡された場合、以下の観点でスコアリングして候補を提示する。

評価基準（詳細は references/scoring-criteria.md）:

観点	高スコアの条件
再現性	他のエンジニアが同じ状況に遭遇する可能性が高い
具体性	具体的な選択肢・トレードオフ・結果がある
意外性	直感に反する結論、一般的な推奨とは異なる判断
時事性	最新の技術・ツール・トレンドに関連している
独自性	既存の記事や LT ではあまり語られていない視点

スコアリング結果をユーザーに提示し、次のアクションを AskUserQuestion で確認する：

深掘りするネタを選ぶ
ネタ帳に追加だけする
別のソースを入力する

会話からの発掘

現在の会話テキストやユーザーが貼ったフリーテキストから発信価値のあるポイントを抽出する。

発掘のアンテナ:

「なぜ A ではなく B にしたか」という判断プロセス
「やってみたら想定外だった」という実体験
「これは知らなかった」という自分の驚き
「これを知っていれば時間が節約できた」という知見

発掘したポイントを以下の形式で提示し、AskUserQuestion で次のアクションを確認する：

## 発信ネタ検出

### ★★★ [タイトル]
- 再現性: 高（理由）
- 具体性: 高（理由）
- 推奨チャネル: [チャネル名]
- フック案: 「[案]」

確認する選択肢:

このネタを深掘りする（チャネル選択へ）
ネタ帳に追加だけする
別の話題を入力する

Stage 2: 社内情報の検出と抽象化

Stage 2 の実行判断

ネタのソースを受け取った後、以下の基準で実行するかを判断する：

常に実行する（以下のいずれかが含まれる場合）:

社名・チーム名・プロジェクト名などの固有名詞
売上・ユーザー数・KPI などの数値
人名

スキップ可（以下の場合）:

ADR テキストに固有名詞・数値・人名が含まれない
ユーザーが「社内情報なし」と明示した場合

判断が難しい場合は「社内情報のチェックが必要ですか？」を AskUserQuestion で確認する。

検出対象（詳細パターンは references/abstraction-patterns.md）:

カテゴリ	抽象化の方向性
組織名（社名・チーム名・プロジェクト名）	「ある決済系スタートアップ」等に一般化
人名	削除、または「PM」「テックリード」等の役割表記に変換
数値（売上・ユーザー数・KPI）	削除、またはオーダー表記（「数十万ユーザー」）に変換
インフラ・社内ツール名	カテゴリ表記（「社内 CI 基盤」「決済代行サービス」）に変換
契約情報（ベンダー名・料金体系）	削除、または「有料プラン」等の一般的な記述に変換

抽象化フロー:

検出した社内固有情報をリスト表示（原文 → 抽象化案）
ユーザーが承認・修正（AskUserQuestion で確認）
「他にも公開すべきでない情報が含まれていないか、最終確認をお願いします」と必ず添える
承認後、抽象化済みの全文を出力してユーザーが通読できるようにする

Stage 3: チャネル別の構成整形

ユーザーが選択したチャネルに合わせてネタを整形する。チャネルテンプレートの詳細は references/channel-templates.md を参照。

チャネル選択

チャネルが未確定の場合は AskUserQuestion で確認してから整形に進む。 Stage 1 の AskUserQuestion またはネタ指定パターンでチャネルが確定済みの場合はスキップ。

対応チャネル

チャネル	出力形式
LT（5 分）	スライド構成案（タイトル + 各スライドの要点）
LT（15〜20 分）	スライド構成案 + スピーカーノート概要
技術ブログ	記事の下書き（Markdown）
Twitter / X スレッド	連投構成（1 ツイートずつ）
社内共有（勉強会等）	要点まとめ + ディスカッションポイント

共通の構成原則

フック→コンテキスト→判断→根拠→結果→学びの6ステップ構造を基本とする。詳細は references/channel-templates.md の冒頭セクションを参照。

構成案を出力した後、AskUserQuestion で次のアクションを確認：

別のチャネル向けに再整形する
このネタをネタ帳に追加する
別のネタに進む

Stage 4: ネタ帳の管理

既存のネタ帳がある場合は、冒頭にテキストを貼ってから操作を指示してください。スキルはセッションをまたいで状態を保持しません。

発掘したネタを Markdown テーブルで管理する。

# Content Seed ネタ帳

| # | タイトル | ソース | 評価 | チャネル | Status |
|---|---------|-------|------|---------|--------|
| 1 | ... | ADR-0001 | ★★★ | LT, ブログ | Draft |

Status: Idea → Draft → Review → Published / Archived

操作一覧

操作	トリガーフレーズ例	動作
追加	「ネタ帳に追加して」「記録して」	新規行を追加して全文を出力
Status 更新	「ドラフトにして」「発信済みにして」	対象行の Status を変更して全文を出力
一覧表示	「ネタ帳を見せて」「一覧を出して」	現在のネタ帳テーブルを出力
検索	「LT 向けのネタは？」「★★★のネタは？」	条件でフィルタした結果を出力

各操作後は変更後の全ネタ帳を出力する。保存はユーザーに委ねる。

ADR Capture スキルとの連携

ADR Capture が生成する ADR の以下の構造を前提に動作する：

フロントマター（Status, Date, Tags）— フィルタリングに使用
Tags — ジャンル別の抽出に使用（[architecture], [library], [testing] 等）
Alternatives Considered — 「なぜ A ではなく B か」の素材

ADR がない場合でも、会話ログやフリーテキストからのネタ発掘は単体で機能する。

フォールバック

状況	対処
ソースが渡されない	入力ソース（ADR / 会話 / フリーテキスト）を AskUserQuestion で確認する
ネタ候補が見つからない	評価基準を緩めて再スキャン。それでもなければ「別の ADR や別の話題はあるか？」と確認
ネタ候補が多すぎる（10件以上）	★★★のものだけに絞って提示し「他にも候補があります。絞り込み条件を指定しますか？」と案内する
社内情報の判断に迷う	「公開しても問題ない情報か最終確認をお願いします」と案内し、ユーザーの判断に委ねる
抽象化案に不満がある	ユーザーが直接修正し、修正版をベースに構成を続行する
Stage 途中でネタをキャンセルしたい	Stage 1 に戻り「別のネタを選ぶ / 別のソースを入力する / Archived で保存する」を AskUserQuestion で確認する

content-seed