kelly-writer

Kelly Writer

アプリ UI のスクリーンショット

概要 チャネル別の内訳と、次に対応が必要な下書き。	下書き チャネルに合わせた下書きのレビューデューキュー。タイトルと本文の編集、レビューコメント、承認コントロールを備えています。

概要

Kelly Writer は、Busabase Cloud の App-in-Skill です。標準のプロダクト画面は Busabase の AirApp であり、ローカルデータを扱う独立したプロダクトではありません。同じ Hono ソースを使い、明示的なリクエストに応じて、OAuth 接続の初期設定を伴うローカルプレビューを実行できます。このスキルを使うと、1 つのアイデア、ブログ記事、トランスクリプト、アウトライン、または製品発表をもとに、編集可能な複数チャネル向けのコンテンツ一式を作成できます。対象は、小紅書、WeChat、ニュースレター、LinkedIn、X/Twitter、ショート動画の台本、SEO 用スニペット、公式ブログの下書きです。

デフォルトの動作は AirApp 優先です。ユーザーが説明だけを明示的に求めた場合を除き、下書きを Busabase に直接生成し、クリック可能な AirApp の URL をユーザーに提示してください。localhost を起動するのは、ローカルプレビューやデバッグを明示的に求められた場合に限ります。localhost も同じ Busabase リソースを使用します。「纯聊天」、「chat only」、「不要打开 UI」など、ユーザーがチャットのみを希望した場合に限り、チャットのみのモードを使用してください。そのモードでは、番号付きの下書き（Draft #1）を提示し、会話内で承認を受けてください。

このスキルは App-in-Skill パターンの実装です。Codex／エージェントのスキルと、レビューおよび承認用の小規模なコンパニオン UI を組み合わせています。仕様書はこちらです：https://mr-kelly.github.io/research/app-in-skill-specification-for-pairing-agent-skills-with-a-local-companion-ui.pdf。

必須の依存関係

1. プロダクトの動作、ビジュアル品質、レスポンシブレイアウト、および標準の content/kelly-writer-app/ 成果物一式については、$kelly-app-skill-creator を読み、従ってください。
2. 接続、対象 Space、ノードの検出、ChangeRequests、レビュー、マージの動作については、$busabase を読み、従ってください。
3. リソースのモデリング、AirApp のランタイム制限、セキュリティ、検証、デプロイについては、$busabase-app-creator を読み、従ってください。

依存関係を利用できない場合は、このスキルのローカル成果物とプロダクトの契約を維持し、利用できない Busabase 操作の直前で停止して、不足している依存関係を正確に報告してください。別のデータバックエンドを作り出してはいけません。

境界

• このスキルでは、ソースの中心的なアイデア、裏付けとなる根拠、例を抽出し、チャネルごとのバリエーションを作成して、すべてを Busabase に書き込むことができます。
• AirApp が読み書きするのは Busabase のレコードのみです。外部プラットフォームへの公開、投稿の予約、メディアのアップロード、その他の外部への副作用を行ってはいけません。また、コンテンツの生成やローカルへのエクスポートも行いません。これらは信頼されたスキルルートのスクリプトが担当します（下記参照）。
• エクスポートには必ず承認が必要です。scripts/export_decisions.mjs は approved の下書きをローカルの Markdown+ZIP パックにまとめて done にしますが、どこにも公開しません。
• ソース素材と下書きはユーザーのコンテンツとして扱ってください。ソースに含まれていない成果、日付、顧客事例、統計、価格、法務・コンプライアンスに関する記述、推薦を決して作り出してはいけません。

Busabase リソース

1 つのアプリケーションフォルダー（kelly-writer）に 2 つの Base があり、content/kelly-writer-app/app/js/config.js と、content/ 配下の生成されたテンプレートサイドカーで宣言されています。

• drafts：レビューキューです。チャネルの下書きごとに 1 件のレコードを持ちます（タイトル、本文、フック、CTA、ハッシュタグ、タイトル案、メディア概要、ソースメモ、リスク、正規アイデア、ソースの要約、エクスポート時のローカル画像パッケージングに使用する source-draft-path）、ワークフローの status、および人間による判定フィールド decision-note／decided-at を含みます。
• settings：kind ごとに 1 行を持ちます。任意の kelly-writer-profile（ブランド、オーディエンス、公式 URL、CTA のデフォルト値、チャネルのデフォルト値、リスク用語、エクスポート設定）と kelly-writer-lock が含まれます。

リソースは、アプリが Space で初めて実行されるときに、冪等性のある Busabase ChangeRequest を通じて遅延プロビジョニングされます。メトリクスとチャネル別の内訳は、読み込みのたびにクライアント側で drafts Base から計算され、保存されることはありません。

このスキルの Busabase 導入前のローカルファイル形式にあったトピック発見／ToDo キュー／正規のメイン下書きのアイデア出しの各段階は、その形式の Busabase プロバイダーノートでもローカルのみで一時的なものでした（クライアント側で導出され、永続化されません）。この Busabase のみの形式では、永続化される作業単位であるチャネルごとの下書きレコードのみをレビューキューとして保持します。

ローカルアプリ

デフォルトの動作では AirApp を優先し、ユーザーにはクリック可能な AirApp URL を提示します。ローカルプレビュー／デバッグを明示的に求められた場合にのみ、pnpm --dir content/kelly-writer-app dev を実行します。

必須のアプリビュー（ハッシュルート）：

• #/overview：メトリクス（レビュー待ち／承認済み／完了／ブロック済み）、チャネル別の内訳、まだレビューが必要な上位の下書きを表示します。
• #/drafts：ワークフローの状態が needs_review、to_approve、changes_requested、approved、done、blocked のチャネル下書きのレビューキューです。各項目には、安定した参照番号（#3）、チャネル／形式／ステータスのバッジ、編集可能なタイトルと本文、ハッシュタグ／CTA／メディア概要／タイトル案のサポートパネル、Review note テキストエリア、および判定を下書きレコードに直接書き込む Approve／Request changes／Block ボタンを表示します。
• #/settings：サニタイズされた設定の概要です。ブランド／オーディエンス／トーン、設定済みチャネル、オンボーディングの状態、および次に実行する正確な node scripts/generate_batch.mjs／node scripts/export_decisions.mjs コマンドを表示します。シークレットの値は決して公開しません。

デモモード：

• ?demo=1（または ?demo=overview）を指定すると、ドキュメントやスクリーンショット用の決定論的なモックコンテンツバッチ（「ローカルファーストな AI ワークフローの実践的なローンチガイド」）が開きます。
• ?demo=drafts と ?demo=settings を指定すると、名前付きのモックシーンを選択します。
• lang=en または lang=zh を指定すると、スクリーンショット用に UI の表示言語を固定できます。
• デモモードでは Busabase の読み込みも書き込みも行いません。

UI 言語：英語と中国語の UI 表示に対応し、デフォルトは Auto にします。タイトル、フック、本文、ハッシュタグは元の言語のままにします。

レビューワークフロー

人間による判定（approve／request_changes／block／revise）では、新しい status と decision-note／decided-at を（approve または revise の場合は編集済みの title／body も）busabase-sdk を通じて下書きレコードに直接書き込みます。スタンドアロンのローカルプレビューでは、書き込みは直ちにマージされます（信頼されたオペレーター）。デプロイ済みの AirApp では、信頼されたプロセスがマージするための保留中の ChangeRequest が作成されます。

スクリプト

どちらのスクリプトも、独自の package.json（busabase-sdk 依存関係）を持つ、信頼されたスキルルートの Node プロセスです。AirApp ブラウザーがこれらを実行することはなく、bases.createChangeRequest を呼び出したり、ローカルファイルを書き込んだりすることもありません。

• node scripts/generate_batch.mjs --source <path-or-text> [--channels official_blog,xiaohongshu,wechat,newsletter,linkedin,x] [--audience "..."] [--cta "..."] [--source-draft-path <path>] [--apply] ソース（ファイルパスまたはインラインテキスト）を読み込み、チャネルごとの決定的な下書き作成ヒューリスティックを適用します（初稿のみ。Codex がその後、各下書きを判断を踏まえて改善する必要があります。レコードの title／body を編集するか、同じレコードに対する判断を通じて改善します）。チャネルごとに新しい drafts レコードを 1 件ずつ Busabase に書き込みます。--apply を指定しない場合はドライランとなり、作成予定の下書きだけを出力します。
• node scripts/export_decisions.mjs [--apply] [--out <dir>] Busabase を再読み込みして、status: "approved" の下書きを取得します。それぞれを Markdown ファイル（タイトル／チャネル／形式／レビューコメント／本文／CTA／ハッシュタグ／メディア概要）と ZIP アーカイブ（Markdown と、元のソースの隣にあるローカル参照画像。source-draft-path と KELLY_WRITER_CONTENT_ROOT を使って解決）にまとめ、スキルルートの exports/<batch-id>/ に保存します。その後、各エクスポート済み下書きを done に更新します。--apply を指定しない場合はドライランとなり、エクスポート予定の内容だけを出力します。

通常のワークフロー

1. モードを判定します。デフォルトは App UI です。
2. ソース、対象読者、希望するチャネル、言語、CTA を確認するか、推測します。
3. node scripts/generate_batch.mjs --source ... --apply を実行して、チャネルごとの下書きの新しいバッチを Busabase に書き込みます。その後、各下書きの title／body を判断を踏まえて改善してから、バッチをユーザーに渡します（生成ツールのヒューリスティックは初稿です）。
4. 下書きを確認、編集、承認できるよう、AirApp の URL（またはローカルプレビュー URL）をユーザーに伝えます。
5. 下書きが changes_requested に移された場合は、レビューコメントに沿って下書きを作り直し、needs_review に戻します。
6. 「承認済みの下書きをエクスポートして」という指示を受けたら、node scripts/export_decisions.mjs --apply を実行して、承認済みの下書きをすべてチャネル対応の ZIP パックにまとめて exports/ に保存し、done に更新します。このスキル自体がどこかに公開することはありません。エクスポートしたパックを公開用コネクターに渡すには、別途、明示的な許可が必要です。
7. 明示的な approve の判断なしに下書きをエクスポートしてはいけません。また、すでに done の下書きを再エクスポートしてはいけません。

コンテンツ生成ルール

• ソースの主張を維持します。成果、日付、顧客事例、統計、価格、法務／コンプライアンスに関する記述、推奨を捏造してはいけません。
• 必要な根拠、製品の詳細、スクリーンショット、リンク、ポリシー上の事実がソースにない場合は、質問するか、needs_review／ブロック状態にします。
• プラットフォーム向けの調整と翻訳を分けて考えます。チャネル形式の変更は可能ですが、約束する内容を変えてはいけません。
• 汎用的で意欲をかき立てるだけの文章より、具体的な導入、詳細、読者にとっての利点を優先します。
• CTA とリンクは、設定プロファイルまたはユーザーの明示的な依頼に沿ったものにします。
• 中国語で作業する場合は、ソースまたはユーザーが別の言語を求めていない限り、自然な簡体字中国語をデフォルトで使用します。
• Xiaohongshu 向けには、スクロールの手を止めるタイトル、短く構成された本文、任意の画像／カルーセル概要、ハッシュタグ一式を作成します。
• ニュースレターや WeChat などの長文コンテンツに展開する場合は、ニュアンスと構成を維持し、アイデアをスローガンに縮めないようにします。
• 短いソーシャル投稿は、それぞれ単独で意味が通じるようにします。読者が元のブログを見ていることを前提にしてはいけません。

チャネル固有の形式を選択または調整する際は、 references/channel-playbook.md を参照してください。

安全に関するデフォルト設定

• エクスポートには承認が必要なものとして扱います。明示的な approve の判断がない下書きは、scripts/export_decisions.mjs の対象にはなりません。
• レビューに必要な最小限の内容のみを保存します。下書きやログにはシークレットや Busabase の認証情報を含めないでください。
• 安定した ID（draft_id、ref、batch_id）を維持し、更新やエクスポートを繰り返しても冪等になるようにします。

チャットのみのモード

ユーザーが UI を使わないよう求めた場合：

1. 簡潔なチャネル計画を作成します。
2. チャネル、タイトル／フック、本文、CTA、メモを含む番号付きの下書きを提示します。
3. 承認または修正を求めます。
4. 承認後、ユーザーがファイルを希望する場合は、node scripts/export_decisions.mjs --apply を実行するか、承認済みの最終パックをローカルの Markdown に直接書き込みます。

ユーザーが公開コネクタを明示的に使用し、公開に成功した場合を除き、コンテンツが公開されたと主張してはいけません。