バンガー解説 — 共有されても生き残る教材コンテンツ は何をしますか？
教材コンテンツは二つの方向で失敗します。個性が強すぎると読者は楽しめますが再現できません。仕様が多すぎると、誰も共有しないドキュメントのように読めます。この手順は、各レジスターをそれが実際に得意とする部分に割り当てます。
最初に読み込む
${CLAUDE_PLUGIN_ROOT}/references/frameworks/voice-and-audience.md— オーディエンスプロファイルと作成者のハード制約。${CLAUDE_PLUGIN_ROOT}/references/frameworks/technical-clarity.md— フレーム/ペイロードの分割とペイロードの規律。ここが主要参照。${CLAUDE_PLUGIN_ROOT}/references/frameworks/writing-quality.md— ライブゲート。配信前に実行。${CLAUDE_PLUGIN_ROOT}/references/platforms/platform-playbook.mdの対象プラットフォームセクション。
新鮮さゲート
このスキルまたはプレイブックからのプラットフォームベンチマーク、アルゴリズムの主張、数値パフォーマンスの主張を使用する前に、references/research/source-ledger.md で有効期限が切れていないサポートを確認してください。サポートがないか、レビュー期限を過ぎている場合は、banger-research を実行し、その主張を「未検証」とラベル付けするか、省略してください。
ステップ1: メカニズムに名前を付ける
自分のためだけに一文を書いてください。読者はこれを理解した後、以前は知らなかった何を理解するのか？ 1つの作品につき1つのメカニズム。2文かかる場合は、2つの作品です。
次に、読者がおそらく今抱いている間違ったモデルに名前を付けます。強力な技術コンテンツは、空白を埋めるのではなく、間違ったモデルを置き換えます。その間違ったモデルが通常はフックになります。
ステップ2: 証明を確認する
草稿を書く前に、以下に名前を付けてください：
- アーティファクト（リポジトリ、ファイル、コミット、スクリーンショット、エラーテキスト、ベンチマーク）、
- 実際に何が起こったか（失敗した部分を含む）、
- テストされていないことは何か、明確に述べてください。
アーティファクトがない場合、これは解説ではなく意見記事です。banger-threads または banger-longform-written にルーティングし、そのように伝えてください。
ステップ3: 説明の深さを設定する
voice-and-audience.md のオーディエンスプロファイルを使用します。第一の原則が支配します：語彙をオーディエンスの実際の洗練度に合わせます。
- 非専門家オーディエンス — すべてのプリミティブを同じ息で、平易な類推を使って定義します。正確な画面、プロンプト、結果を示します。ペイロードは長くなり、ステップは小さくなります。決して見下すような言い方をしないでください。
- 実践者オーディエンス — 業界内の省略表現は自由に使い、過剰な説明は彼らの時間を無駄にします。トレードオフ、失敗モード、そしてあなたが違う方法で行うであろうことにスペースを割いてください。
ステップ4: 分割して草稿を書く
フレーム（著者の声。明確さのルールではない）:
- カテゴリではなく、特定の間違ったモデルまたは特定の苦痛に名前を付けるフック。
- ストーリー：何をしていたか、何が壊れたか、どれだけのコストがかかったか。
- 判断：今何を考えているか、そしてその自信の度合い。
- プラットフォーム固有の行動喚起。
ペイロード（技術的な明確さ）:
- 概念ごとに1つの名前、作品全体で統一。
- 一文につき1つのアイデア、約25語、ステップでは20語に近づける。
- 能動態、名前のある行為者：「パーサーがファイルを読み取る」。
- 動詞を使い、名詞化は避ける。数字を示し、品質を主張しない。
- 具体的なアーティファクト：実際のコマンド、実際のエラー、実際のパス。
縮約形、余談、ユーモア、意見は、それらが重みを持つペイロード内に留めてください。規律は平坦化と同じではありません。
ステップ5: プラットフォームの形状
- X または Bluesky スレッド — 投稿ごとに1つのメカニズムステップ。フレームは最初の投稿と最後の投稿。ペイロード投稿には可能な限りコードブロックまたはスクリーンショットを含めます。メカニズムが必要とする以上に長くしないでください。
- LinkedIn — 最初の150文字以内にフック、間違ったモデルのフレーミング、その後3～4つのペイロードビートを短い段落で。判断と質問で締めくくります。本文にリンクは入れないでください。
- ニュースレターまたはSubstack — メカニズムステップごとにヘッダー、ステップごとに図またはコードブロック、判断をプルクォートします。ペイロードから抽出したスタンドアロンのNotesを提供します（フレームからは抽出しません）。
- 動画説明またはドキュメントスタイルの投稿 — ペイロードが優勢、フレームは2行に縮小。
- Facebookグループ — この手順は使用しないでください。
banger-longform-writtenにルーティングし、質問主導で短くします。
ステップ6: 配信前に検証する
writing-quality.md ゲートを実行し、次に以下を実行します：
- 読者は投稿を閉じた状態でメカニズムを再現できるか？
- すべての概念が正確に1つの名前で呼ばれているか？
- 品質を示す代わりに品質を主張しているものはないか？
- フレームはまだ著者が声に出して言ったように聞こえるか？
- すべての数字、引用、結果が実際のアーティファクトにトレース可能か？
- 作成者のハード制約（禁止された句読点、フレーズ、トーン）が満たされているか？
出力形式
完成したアセットを先頭に、貼り付け可能な状態で、プラットフォーム用にフォーマットして出力します。次に：
- メカニズム文とそれが置き換える間違ったモデル、
- 各主張がトレースされるアーティファクト、
- 「未検証」とラベル付けされたもの、
- 次に必要な承認。
草稿は自由です。公開、スケジュール設定、アウトリーチには、作成者の明示的なアイテムごとの承認が必要です。