content-factory

COG コンテンツファクトリーのスキル

目的

ユーザーに代わる自律型コンテンツクリエイターとして行動します。ユーザーの分野で何が起きたばかりかを調査し、本当にトレンドになっているものを選び、重複を一切生じさせず、厳格な投稿数の上限を守り、公開済みとして扱う前に検証したうえで、ユーザーらしい文体のコンテンツに仕上げます。夜間などのスケジュールに従って無人で実行でき、安全に再実行できるよう設計されています。何も出力しない実行も有効な実行です。品質の低い投稿は有効ではありません。

呼び出すタイミング

• /content-factory ／「コンテンツファクトリーを実行して」
• スケジュールされた実行（例：cron／launchd による夜間の 2～4 回の実行）
• 「今日のニュースをコンテンツにして」

前提条件

ユーザーの文体と注力分野は 00-inbox/MY-PROFILE.md から、トピックは 00-inbox/MY-INTERESTS.md から読み込みます。公開先は 00-inbox/MY-INTEGRATIONS.md から取得します。無効になっているチャンネルは、何も伝えずにスキップします。

状態ファイル（最初に読み込み、最後に更新する — 重複排除の要）

• 04-projects/content-factory/ledger.md — これまで取り上げた／公開した内容すべて（トピックのスラッグ、ソース URL、形式、リンク、日付）。本当に新しいニュースがある場合を除き、台帳に記録済みのトピックやソース URL は絶対に再利用しないでください（続報は新しいニュースに該当しますが、同じ発表の言い換えは該当しません）。
• 04-projects/content-factory/tonight-<YYYY-MM-DD>.md — 今夜の実行ログ（夜の初回実行時に作成）。それ以前の実行で調査、保留、作成、公開した内容と、残りの投稿数を記録します。
• 04-projects/content-factory/sources.md — 監視リストです。有用だと判断したソースを追加し、無効になったものは削除します。

投稿数の上限（1 晩の全実行を通じた厳格な上限）

チャンネル	1 晩あたりの上限	備考
短文のソーシャル投稿／スレッド	2	投稿数の多いチャンネルです。スレッドも 1 件として数えます
ブログ記事	1	内容に見合う場合のみ
短い動画	1	アイデアが視覚的、またはデモに適している場合のみ
長文のプロフェッショナル向け投稿	1	専門的な観点から強く訴求できる場合のみ
長尺動画／詳細なエッセイ	0	自律的には作成しません。実行ログで提案してください

上限は今夜のファイルで管理します。後続の実行では、残りの上限を引き継ぎます。上限は好みに応じて調整してください。ただし、上限を設け、実行ごとではなく複数回の実行全体を通じて適用することが必須です。

フェーズ 1 — 調査（毎回実行）

1. ユーザーの監視対象トピックについて、過去 24 時間の発表と、すでにトレンドになっている話題をウェブ検索します。
2. sources.md にある監視対象ブログや変更履歴を取得します。
3. ブラウザー連携が利用できる場合は、ユーザーのソーシャルフィードを確認してエンゲージメントの兆候を調べます。生のエンゲージメント数は、トレンドを把握するうえで最も有力なシグナルです。
4. 調査の作業時間は約 20 分に制限します。

フェーズ 2 — 選別（雰囲気ではなくスコアで判断）

候補ごとに、次の項目を 1～5 点で評価します。

• (a) トレンドの勢い — 主要アカウントやアグリゲーターが、今まさに話題にしていますか？
• (b) 注力分野との適合性 — ユーザーの注力分野（MY-PROFILE.md 参照）のいずれかに合致していますか？
• (c) 独自の切り口 — 実験、実践者の見解、異論を唱える解釈など、このユーザーにしか加えられないものを提供できますか？誰にでも書ける要約ではありません。

合計 11 点以上 → 作成します。8～10 点 → 今夜のファイルに保留し、後続の実行で再評価します。8 点未満 → 無視します。

作成前に重複を確認します。トピックのスラッグとソース URL を台帳と照合し、さらに確認できる場合はユーザーの直近の公開済み投稿（約 20 件）とも照合します。

フェーズ 3 — 作成（形式は内容に合わせて選び、野心で決めない）

• デフォルト：短い投稿またはスレッドを 1 件 — 冒頭のつかみ、添付メディア、最後にリンク、ハッシュタグは最小限にします。
• ブログ記事は、独自に述べることが 3 点以上ある場合、または実際の成果物を伴う実証可能な概念実証がある場合のみ作成します。ユーザーに PoC の注力分野がある場合は、実際に小規模な PoC を作成します（作業時間は約 45 分に制限）。失敗も含め、実際の結果を公開してください。PoC の結果を捏造してはいけません。「ここで壊れた」も価値のあるコンテンツです。
• 短い動画は、アイデアが視覚的、または 60 秒以内のデモに適している場合に作成します。
• すべてを相互リンクします（動画 ↔ ブログ ↔ スレッドが互いに参照し合うようにします）。

フェーズ 4 — 公開（安全性のゲート）

1. 環境ゲート：公開先が利用できない場合、またはユーザーがブラウザーやマシンを現在使用していると思われる場合は、公開しないでください。完成したバンドルを 04-projects/content-factory/out/<date>/ に保存し、後続の実行またはユーザーによる公開に委ねてください。
2. 事後条件の確認（必須）：公開するたびに、成果物を確認してください。公開済みの投稿をスクリーンショットで撮影し、公開 URL に curl を実行してから、公開済みとして記録してください。公開呼び出しだけを根拠に成功を報告してはいけません。
3. 議論に加わらず、相手を引用して嘲笑せず、知らない人に返信しないでください。このファクトリーでは、ユーザー自身の公開先にオリジナルの投稿だけを作成します。
4. スクリーンショットはすべて、認証情報の確認に合格する必要があります（アカウントのメールアドレス、トークン、内部 URL が表示されていないこと）。
5. すでに反応が付いた投稿は削除しないでください。修正が必要な場合は、その場で編集してください。

フェーズ 5 — 台帳とログ（実行内容がなくても必ず記録）

• 公開した項目を ledger.md に追記します：| date | slug | beat | formats | source URL | published links |。
• tonight-<date>.md を更新します：調査した項目の一覧、スコア、保留した項目、残りの予算、次回の実行で最初に確認すべき内容を記録します。
• ユーザーが構成を練るべき大きな発表については、概要案を添えて tonight ファイルに提案として記載してください。自律的に作成しようとしてはいけません。

文体チェックリスト（1項目でも不合格なら下書きを削除）

• ニュースボットではなく、作り手が共有しているように聞こえる（「試してみた」「壊してしまった」「意外だったのはこれです」）
• 少なくとも1つ、このユーザーにしか言えない内容が含まれている（ユーザーの環境、数値、PoC、視点）
• AI っぽい空疎な語彙（「画期的」「革命的」「解き放つ」）がなく、絵文字の羅列もなく、ハッシュタグは上限内に収まっている
• メディアが添付され、リンクがあり、機密情報が含まれていない
• 重複していない（台帳と最近の投稿を確認済み）

ループ（/loop-engineering を参照）

毎晩の実行は、予算が尽きるまで実行をまたいでスキャンするループです。tonight ファイルは共有ループ状態、台帳は重複を検証する記録、投稿数の予算は上限、文体チェックリストは品質ゲートです。終了条件：予算を使い切った、スコアが 11 以上の項目がない、または環境ゲートによって公開がブロックされた場合。