breakthrough-content-engine

ブレイクスルー・コンテンツエンジン

目標をひとつ渡せば、コンテンツ一式の計画を作成します。人が確認するのは1枚の表だけで、あとは機械的に導き出します。

これはディスパッチャーです。以下のマップで、各レイヤーがどの references/ ファイルにあるかを確認できます。必要に応じて読み込み、最初からすべて読まないでください。

何が違うのか

ほとんどのコンテンツツールは「テーマをひとつ渡せば、原稿をひとつ作成する」という形です。この仕組みは逆です。ビジネス目標を渡してもらい、まずこの期間に誰を狙い、何を伝え、何本作るべきかを示し、最後に原稿を書きます。

ほかのツールと異なる点は3つあります。

• 配分は導き出すもので、比率をそのまま当てはめるものではありません。 ファネルのどの段階についても、コンテンツ本数の比率を裏付ける実測研究はありません（80/20、4-1-1、70/20/10はいずれも断言にすぎず、70/20/10に至ってはリスク配分がファネル配分として誤って引用されています）。ここで使う数字は、決まり文句ではなく、あなたの制作能力、ファネル診断、運用期間から導きます。制作能力で上限を決め、目標で形を定め、診断で調整し、フォーマットに割り当てます。
• 人が確認するのはseedであり、原稿ではありません。 8〜20件のseed sheetが唯一の人による意思決定ポイントです。十数〜20数マスのコンテンツマップはseedから機械的に導き出せるため、再生成できます。人が20数個のマスをひとつずつ確認する必要はありません。規模は人の判断を支えるためのものであり、人を圧倒するためのものではありません。
• 出力を拒否することもあります。 フォロワー数が足りなければ配分は提示せず、代わりにリーチ獲得タスクリストを作ります。手元に実物の素材がなければ原稿は書かず、代わりに収集指示を出します。「素材が足りないので、まず集めてください」は、正当で適切な出力です。

いつ使うか

• ✅ コンテンツ一式（1か月分、1回のローンチ、一定期間分）を計画したい
• ✅ 投稿を続けても効果がなく、どの段階で漏れているかを知りたい
• ✅ 感覚に頼らず、この期間に動画を何本、画像・テキスト投稿を何本作るべきかを知りたい
• ❌ コピーを1本書きたいだけ → パイプライン全体を実行する必要はありません
• ❌ 有料広告が中心 → 配分ロジックがまったく異なるため、ここではオーガニックのみを扱います
• ❌ まだ製品がなく、購入者もいない → これは製品検証の課題であり、コンテンツの課題ではありません

4つのモード

このスキルには4つの使い方があります。まずどれに当てはまるかを判断してから、先に進んでください。

Mode	いつ使うか	内容	読み込むファイル
Plan	「今月の計画を立てて」「この期間に何本投稿すればいい？」	目標から原稿まで進めるメインフロー。最後に修正内容を反映します	modes/plan.md
Capture	「顧客の発言をいくつか拾った」「NEEDS-CAPTURE の項目を補完した」	実際の素材を集め、scene_id を割り当て、barrier の証拠レベルを引き上げます	modes/capture.md
Log	ベルが知らせたとき、または「成果を記録して」	3／7／15日後の純粋な記録。30秒で完了し、判断はしません	modes/log.md
Review	「振り返りをして」、または1期間を終えて6〜8週間後	データを読み、診断と配分を再実行し、結論ではなく提案を出します	modes/review.md

Capture は、このエンジンで実際の証拠を取り込める唯一の入り口です。 それ以外の場所から得られるのは、すべてコンテキストです。

second-brain vault がある場合

99_Meta/structure-doctrine.md が見える場合は、vault があります。vault がある場合は、最初に references/_vault.md を読んでください。ビジネス領域を確認してブランドのコンテキストを把握し、オーバーレイ（ユーザー自身が調整した数値を初期値より優先）を読み、情報をどこに置くべきかを確認します。

🛑 各モードの最初の作業は、道筋を確認することです（_vault.md §1.5、セクション全体を実行）。globを1回実行して content-engine-paths.md というアドレス帳を探し、すべてのパスをそこから取得します。見つかったら、続けて同じセクションのベル接続チェックを実行してください。 ⛔ 初回でも100回目でも、記憶からパスを推測してはいけません。ビジネス領域とブランド名の組み合わせはユーザー自身が決めたものなので、推測できません。

⚠️ 確認した内容はコンテキストであり、証拠ではありません。 8本柱の基盤やブランド戦略レポートは証拠のように読め、引用符まで付いていることがあります。しかし、実測では100KBの確定済み戦略から、confirmed の顧客 barrier は0件でした。そのため、vaultを確認する際は、最初に引用元を調べ、出典が示されていないものはすべて構成された内容として扱います。

vault がなくても実行できます。00-intake.md に従って6つの項目を尋ねてください。⛔ vault はあると便利なものであり、前提条件ではありません。

ベル接続（道筋の確認時に実施。⛔ インストール時ではありません）

ユーザーが製品によって生成された command-base skill を持っている場合、エンジンはすでにインストールされているユーザー自身のものを変更します（製品のテンプレートではありません。テンプレートが影響するのは今後の新規インストールのみです）。これにより、コンテンツの期限が来たことをベルが認識できるようになります。

⛔ これはインストール時には行われません。 npx skills add はパッケージマネージャーであり、スキル内の指示を実行することはありません。また、インストール時点では、ユーザーの vault がどこにあるかも分かりません。⇒ 実行タイミングは、各モードの開始時に道筋を確認した直後（_vault.md §1.5 の「道筋を確認したあとにもう1つ」）です。⛔ _vault.md §8 ではありません。 §8 はアドレス帳が存在しない場合にのみ実行されるため、すでにアドレス帳があるユーザーには実行されません。

⚠️ 製品側のベルの原則：ベルが鳴るのは1回だけで、期限が来た項目はベル自身が知らせます。ユーザーに選択肢を提示することはありません（製品の modes/maintenance.md にある「One doorbell, two files」で説明している内容です）。そのため、2つ目のベルは追加しません。「3／7／15日経過した投稿はどれか」を、既存のベルが読み取れる場所に書き加えるだけです。ベルは1回だけ鳴り、知らせる内容が1つ増えます。

⛔ 変更するのは、Claude Code が実際に読み込むファイル（~/.claude/skills/<slug>-command-base/SKILL.md）です。vault にあるファイルはコピーしてインストールした場合の複製にすぎず、変更してもエラーにならず、反映もされません。変更後は grep で読み戻して確認してください。⛔ ベルのブロック自体には書き込まないでください。製品のアップグレードでそのブロック全体が上書きされます。

どのファイルを、どこに、何を書き込み、再実行時に二重挿入をどう防ぎ、接続できない場合にどう記録するかの5項目は、すべて _vault.md §1.5 と §9 にあります。⛔ この段落の記憶だけを頼りに作業しないでください。

実行時は、以下のレイヤーを順番に進めてください

レイヤー	内容	担当	ファイル
L0	目標、期限、制作能力、プラットフォーム、フォロワー数を収集	質問	00-intake.md
L0.5	規模ゲート：規模が足りなければ配分を提示しません	ゲート	00-intake.md
L1	ファネル診断を行い、stage-pressure profile を作成	エンジンが提案	01-diagnosis.md
L2	メインラインを提案。カードを2〜3枚提示	人が選択（意思決定ポイント1）	02-mainline.md
L3	配分：各段階・各フォーマットの本数、投稿先のプラットフォーム数	エンジンが提案し、人が数値を変更可能	03-package-model.md
L4	Seed sheet	人が確認（意思決定ポイント2、唯一の確認）	05-seed-sheet.md
L5	コンテンツマップを機械的に作成	エンジン	06-content-map.md
L6	1項目を選んで原稿を作成	エンジン	07 → 08 → 09 → 10

必要に応じて読み込む

ユーザーの要望	読むファイル
新しい期間の計画を始める／「今月の計画を立てて」	00-intake.md
「コンテンツが見られないのはなぜ？」／どの段階でつまずいているか診断する	01-diagnosis.md
メインラインを決める／「どんな切り口で話せばいい？」／reframe	02-mainline.md
「この期間に何本作ればいい？」／配分／どのプラットフォームに投稿するか	03-package-model.md
コンテンツの種類を選ぶ／「どんなコンテンツを投稿できる？」	04-content-types.md
seed sheet を作成する／seed を確認する	05-seed-sheet.md
コンテンツマップを作成する／コンテンツ同士をどうつなげるか	06-content-map.md
原稿を1本書く／1本の構成を知る	07-body-structures.md
プラットフォームごとの投稿方法を知る	08-formats/（プラットフォームに応じて1つ選ぶ）
タイトル／冒頭の一文／動画のフックを考える	09-hooks/（最初に _tournament.md を読む）
原稿がAIっぽく読める／原稿作成前のチェック	10-voice-anti-ai.md
「書くための素材がありません」	11-capture-loop.md
期間全体をまとめて実行する／一括処理	12-batch.md
vault がある／オーバーレイの値／情報の保存先	references/_vault.md
ルールを変更したい／ある判断の理由を知りたい	references/_RULINGS.md（裁定の正本。⛔ ルールを変更する場合は、まず本体のファイルを変更し、その後に戻って裁定と理由を記録してください）
このユーザー自身が調整した数値や、得られた知見	vault の 04_Methodology/Playbooks/Content-Engine/

几条贯穿全场的规矩

这几条在很多档里会重复出现，因为它们真的到处适用：

• 遮品牌名测试。 把品牌名盖掉，如果这条内容随便哪个同行都能发，它就失败了。一看就知道是你，才算成功。
• 免费老师陷阱。 知识很廉价，AI 随便生成；观点才值钱。干货类内容最容易踩，每一条都必须带你自己的方法和立场。
• 深 ≠ 独特。 往下挖情绪、挖身份，挖到最后往往挖到一个人人适用的普适真相。那是最高级的同质化，不是洞察。差异化来自 reframe（你的视角），不是来自挖得更深。
• Awareness 里一 pitch，三个阶段塌成一个。 认知阶段的内容里出现产品，读者直接划走。这条没有例外。
• 只准真实稀缺，不准制造紧迫。 在错的阶段用制造出来的急迫感，是分类错误，不是风格选择。
• 真实记忆有废料，编造的记忆没有。 一篇稿子里如果每一个细节都刚好在替论点服务，一个多余的都没有，那多半是编的。而那个多余的细节必须跟承重细节同源，否则随手编一个无关细节就能过关，这条规则就白写了。

一句话

内容是慢功夫。先有真材料，再有角度，再有内容。 这套工具能做的是让每一步都有依据，不能替你去把顾客说过的那句话捡回来。