kelly-writer

Kelly Writer

应用 UI 截图

概览 各渠道的内容拆分，以及接下来需要关注的草稿。	草稿 适配各渠道的草稿审核队列，支持编辑标题和正文、添加审核备注并进行审批。

概览

Kelly Writer 是一款 Busabase Cloud App-in-Skill。其标准产品界面是 Busabase 中的 AirApp，而不是单独的本地数据产品。相同的 Hono 源代码支持通过 OAuth 连接初始化，并可按明确请求启动本地预览。使用此技能，可将一个想法、博客文章、文字稿、 大纲或产品公告转化为可编辑的多渠道内容批次：小红书、微信公众号、新闻简报、LinkedIn、X/Twitter、短视频 脚本、SEO 摘要，以及官方博客草稿。

默认优先使用 AirApp。除非用户明确只要求解释，否则应直接在 Busabase 中生成草稿，并向用户提供可点击的 AirApp URL。只有在用户明确要求本地预览或调试时才启动 localhost；它使用相同的 Busabase 资源。仅当用户说“纯聊天”“chat only”“不要打开 UI”或 类似内容时，才使用纯聊天模式；在此模式下，以编号形式展示草稿（Draft #1），并在对话中征求审批。

此技能是 App-in-Skill 模式的实现——将 Codex/Agent 技能与用于审核和审批的小型配套 UI 组合在一起。 参见规范论文：https://mr-kelly.github.io/research/app-in-skill-specification-for-pairing-agent-skills-with-a-local-companion-ui.pdf。

必需依赖项

1. 阅读并遵循 $kelly-app-skill-creator，以满足产品行为、视觉质量、响应式布局，以及完整的标准 content/kelly-writer-app/ 产物要求。
2. 阅读并遵循 $busabase，了解连接、目标 Space、节点发现、ChangeRequests、审核和合并行为。
3. 阅读并遵循 $busabase-app-creator，了解资源建模、AirApp 运行时限制、安全性、验证和部署。

如果某项依赖不可用，请保留此技能的本地产物和产品约定，在执行不可用的 Busabase 操作之前停止，并报告确切缺失的依赖项。不要另行设计第二套数据后端。

边界

• 此技能可以提取源内容的核心想法、佐证要点和示例，撰写适合各渠道的版本，并将所有内容写入 Busabase。
• AirApp 仅读写 Busabase 记录。它绝不能向外部平台发布内容、安排帖子发布时间、上传媒体，或执行任何其他外部副作用——也绝不生成内容或自行写入本地导出文件；这些操作由可信的技能根目录脚本执行（见下文）。
• 导出始终需要审批。scripts/export_decisions.mjs 仅将 approved 草稿打包为本地 Markdown+ZIP 文件包，并将其标记为 done；绝不会发布到任何地方。
• 将源材料和草稿视为用户的内容。绝不能编造源内容中未提供的结果、日期、客户案例、统计数据、价格、法律/合规声明或背书。

Busabase 资源

一个应用文件夹（kelly-writer）下的两个 Base，定义在 content/kelly-writer-app/app/js/config.js 和 content/ 下生成的模板 sidecar 中：

• drafts：审核队列——每个渠道草稿对应一条记录（标题、正文、 hook、CTA、标签、标题选项、媒体简介、来源备注、风险、 规范化创意、来源摘要，以及用于导出时本地图像打包的 source-draft-path）、工作流 status，以及人工判定字段 decision-note / decided-at。
• settings：每个 kind 一行——可选的 kelly-writer-profile（品牌、 受众、官方 URL、默认 CTA、渠道默认设置、风险用词、导出偏好） 和 kelly-writer-lock。

资源会在应用首次于某个 Space 中运行时，通过幂等的 Busabase ChangeRequest 按需创建。指标和渠道明细在每次读取时都从 drafts Base 在客户端计算——绝不存储。

该技能在采用 Busabase 之前的本地文件结构中，选题发现／待办队列／规范主草稿构思阶段 本来就是仅限本地且临时的（由客户端派生，从不持久化）；即使在该结构自己的 Busabase provider 说明中也是如此。此仅使用 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 语言：支持英文和中文界面，默认使用 Auto。标题、hook、正文和标签保持原语言。

审核工作流

人工判定（approve / request_changes / block / revise）会通过 busabase-sdk 将新的 status 以及 decision-note / decided-at（对于 approve 或 revise，还包括编辑后的 title / body）直接写入草稿记录。在独立的本地预览中，写入会 立即合并（受信任的操作员）；从已部署的 AirApp 发起时，则会创建待处理的 ChangeRequest，供受信任流程合并。

脚本

这两个脚本都是可信的、位于技能根目录的 Node 进程，各自拥有自己的 package.json（依赖项为 busabase-sdk）——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，也可以针对同一记录作出决策），并为每个渠道向 Busabase 写入一条新的 drafts 记录。不加 --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／blocked。
• 区分平台适配与翻译：可以更改渠道格式，但不能更改承诺。
• 相比泛泛的励志文案，优先采用具体的吸引点、细节和对读者的益处。
• CTA 和链接应与设置配置文件或用户的明确要求保持一致。
• 对于中文内容，默认使用自然的简体中文，除非来源／用户要求使用其他语言。
• 对于小红书，撰写吸引人停留的标题、简短且结构清晰的正文、可选的图片／轮播简介，以及一组标签。
• 对于新闻简报或微信公众号等长篇衍生内容，保留细微差别和结构；避免将观点压缩成口号。
• 对于短篇社交媒体帖子，确保每篇都能独立理解；不要假设读者看过原始博客。

选择或调整特定渠道的格式时，请阅读 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）。

除非用户明确使用了发布连接器且操作成功，否则绝不要声称内容已发布。