ce-promote

プロモーション用コピー

リリースしたばかりの機能を、エンジニアリングのワークフロー内で、そのままコピーして使えるユーザー向け告知文にします。別途マーケティングの確認を待つ必要はありません。

完了条件： 作成したすべてのチャネル向けコピーを、ラベル付きのコピー可能なブロックとして提示し、ユーザーに修正の機会を案内します。このスキルが行うのは下書きの作成のみです。投稿、公開、予約、コミット、PR の作成は行いません。 投稿は人間が行います。

Spiral の有無にかかわらず動作します。何もインストールされていない場合は、Path B（直接作成）の編集とソーシャルメディアの基本原則に沿って直接下書きを作成します。Spiral CLI が利用でき、認証済みの場合は、ユーザーのブランドのトーンに合わせた下書きを作成します。これはあくまで機能の拡張であり、必須ではありません。

Phase 1 — リリースした内容を把握する

引数に自由形式で記述された内容がある場合は、それを信頼できる情報源として扱います。ない場合は、利用可能な情報を使ってコンテキストから導き出します。どれか一つの情報源に依存したり、待ったりすることはありません。

• マージ済み／アクティブな PR — gh pr view --json title,body,url（タイトルと本文には通常、ユーザーにとっての価値が記されています）
• 差分 — git diff main...HEAD --stat を確認し、注目すべき変更に目を通して、主張が実際の変更に基づいていることを確かめます
• 変更履歴 — docs/changelog.md、CHANGELOG.md などの先頭または [Unreleased] の項目
• 最近のコミット — 変更の経緯を把握するための git log --oneline -15

次に、ユーザーにとっての価値を1～3文で要約します。ユーザーが新たにできるようになったことと、それがなぜ重要なのかを説明します。実装ではなく成果を伝えます。「レポートをワンクリックで CSV にエクスポートできるようになりました」であり、「CsvSerializer とエンドポイントを追加しました」ではありません。リリース内容を確信を持って判断できない場合は、推測せず、短い質問を一つだけ尋ねます。

Phase 2 — チャネルを選ぶ

デフォルトでは、X の投稿（または短いスレッド）に加えて、変更履歴やリリース向けの一文を作成します。ユーザーが LinkedIn、メール、ブログの導入文、デモ用スクリプトなどのチャネルを指定した場合は、デフォルトのチャネルに代えて、または追加して作成します。変更の規模に合わせます。小さな修正なら短い下書きを1～2件、主要機能なら複数チャネル向けの一式を作成します。固定のテンプレートに無理に当てはめないでください。

Phase 3 — コピーを作成する

短時間で完了する、処理をブロックしない次の2つのコマンドで Spiral の状態を確認します。

which spiral
spiral auth status --json 2>/dev/null

• バイナリがない -> 不在
• "authenticated": true -> 準備完了
• "authenticated": false -> 未認証
• 出力が JSON ではない（古い CLI が --json を無視する場合） -> spiral_sk_ が含まれていれば準備完了、そうでなければ未認証

準備完了の場合は Path A（Spiral の準備完了）に進みます。不在または未認証の場合は Path 0（Spiral のセットアップを案内）に進み、セットアップが完了したら Path A、完了しなければ Path B（直接作成）に進みます。Spiral の失敗、タイムアウト、予期しない出力によって、このスキルをブロックしたり遅らせたりしてはいけません。判断に迷った場合は未準備として扱い、処理を続けます。

Path 0 — Spiral のセットアップを案内する（一度だけ。辞退可能）

非対話形式で実行する場合は、人間が回答できないため、すぐに Path B に進みます。それ以外の場合は、セットアップを一度だけ案内します。references/spiral-cli.md を読み、その Path 0 のセクションに従って、オプトアウトの確認、回答待ちの質問、エージェントが実行する spiral login --json のフロー（API キーがエージェントを経由することも、ユーザーがチャットに貼り付けることもありません）、インストール手順、オプトアウトの記録方法を確認します。Path B に進むのは、その確認で記録済みのオプトアウトが見つかった場合に限ります。何を記録済みとみなすかは同セクションで定義されています。単純な設定のスキャンでは、ce-setup のコメントアウトされたテンプレート例をオプトアウトとして誤認し、案内が気づかれないまま抑止されてしまいます。

同セクションが前提とする重要な点は2つあります。**案内を辞退すると、必ずオプトアウトが記録されます。**そのため、このリポジトリでは初回に一度辞退すれば、その後案内が表示されることはありません。また、辞退した場合は必ず Path B に進み、そこで処理が止まることはありません。人間が対応可能でも、現在のツール一覧に回答待ちの質問を行うツールがない場合は、チャットに2つの選択肢を番号付きリストで提示し、返答を待ちます。案内を省略してはいけません。また、そのツールがあるかを確認する目的で、ユーザー向け質問ツールを呼び出してはいけません。

Path A — Spiral の準備完了（声のトーンを合わせる）

プロンプトを作成する前に、references/spiral-cli.md を読んでください。 Spiral が複数チャンネルのセットを返すか、1 つのチャンネルの複数のバリエーションを返すかは、表現の仕方（チャンネルのキーワードや手がかりとなる語句と、--num-drafts の使い分け）によって決まります。間違えると、誤った数や形式の下書きが何も表示されずに返されるため、これらのルールを記憶だけで言い直さないでください。

常に --instant と --json を渡し、drafts[]（各項目に独自の channel が含まれます）と session_id を解析してください。返された下書きはすべて、channel ごとにまとめて提示してください — 各チャンネルの下書きの数は Spiral が決めるため、チャンネルごとに 1 件だけだと決めつけたり、余分な下書きを省いたりしないでください。spiral write の呼び出しでエラーが発生した場合、または使用可能な下書きが返されない場合は、該当するチャンネルについて、何も告げずに Path B に切り替えてください。

Path B — 直接下書きを作成

Spiral は不要です。ce-noslop スキルを使って、すべてのチャンネル向けに下書きを作成してください。（Spiral を使う方法では、さらにブランドの声のトーンへの適合、人間らしさの調整、保存済みスタイル、複数チャンネルにまたがるキャンペーンのオーケストレーションが行われます。）

すべてのチャンネル共通：

• まず、読者が得られる成果を示します — どのように作られたかではなく、今できるようになることを伝えます。
• 1 つの投稿につき、アイデアは 1 つにします。

複数チャンネルに配信する場合： 1 行目はフックとし、読者が次の行を読みたくなる内容にします（フィードでは途中で切り詰められます）。前置きは不要です。各チャンネルに適した形式と長さに合わせ、同じ下書きを複数チャンネルでそのまま使い回さないでください。そのチャンネルで可能な場合は、明確な CTA を 1 つ入れます。ハッシュタグは 0～2 個とし、そのチャンネルで使われる場合に限ります。

チャンネルごとの要件：

• X — 1 行目で価値を伝えます。簡潔な 1～3 行程度にします。独立した行にする価値のある要点が複数ある場合に限り、スレッドにします。
• 変更履歴／リリース告知 — 新機能を明示する断定的な 1 行にします。宣伝調ではなく、簡潔にします。
• LinkedIn — 短い段落にします。まず、人に関わる観点（なぜ重要か）を示し、次に内容を伝えます。X より温かみのあるトーンにします。
• メール — メリットを示す件名、2～4 文の本文、CTA を 1 つ用意します。
• ブログの導入文 — 問題と新機能を位置づける導入段落を 1 つ作成します。詳しい説明は執筆者に委ねます。
• デモの台本 — 話し言葉で 3～6 個の要点を構成します。フック、課題、操作、成果の順にします。

デフォルトでは、各チャンネルにつき質の高い下書きを 1 件作成します。追加の下書きは依頼された場合（「ツイート案を 3 つ」など）に限り、最大で約 3 件まで作成します。

Phase 4 — 下書きを提示する

すべての下書きを、チャンネル名を付けた、コピーしてすぐに使える形式のブロックで提示します。

### X post
<the copy>

Path A で作成した場合は、session_id と各下書きの url も表示し、ユーザーが Spiral のウェブアプリで開いて調整できるようにします。トーン、長さ、切り口、追加のバリエーション、別のチャンネルへの修正を提案します。投稿、公開、スケジュール設定、コミット、プルリクエストの作成は行わないでください — 最後に、下書きを公開するかどうかはユーザー自身が決めることを伝えてください。