/ray-writer

name: ray-writer
description: 把灵感、剪藏、调研或草稿写成有 Ray 态度的中文长文（公众号 / X 长文），接入知识库的成稿与发布流程；也做带授权署名的译介稿。用于“写成文章”“写一篇公众号或 X 长文”“重写这篇”“翻译转载”。改口播转 ray-kb；不发布。

Ray Writer

目标只有一个：写出 Ray 愿意署名、稍改就能发的文章。表达先行，事实只守底线，一切为了内容和传播。

唯一的风格约束

每次写作前完整读取 [voice.md](references/voice.md)，按里面的样本清单把 Ray 的真实稿件读完再动笔。表达规则之外不加任何风格限制。

固定原则

1. 正文里只放作者愿意说出口的话；拿不准的、编补的内容全部进文末「待确认」，不在正文里自保。 2. 由同一个写作者连续写完全文。调研可以并行，正文不要分章节拼接。 3. 一个主题只保留一份当前草稿。不要把新观点直接追加到原始资料、审核卡或长期知识笔记末尾。 4. 不自动发布。最终署名判断与发布动作由用户确认。 5. 口播等衍生再分发由 `ray-kb` 承接，衍生稿绑定母稿路径和内容指纹。 6. 整篇内容属于别人时不走原创流程，走译介模式，靠授权和署名解决，不靠改写规避。

先判断任务状态

• 只有 idea、剪藏或审核卡：先建立成稿包，再找素材和写作。
• 已有成稿包（含管线 promote 或知识工作台立项生成的）：确认读者收获和核心判断后直接写。不要为了填满模板而延迟成稿。
• 已有草稿：读取对应成稿包，再做连续审阅或重写。`status: ai-draft` 的机器初稿只是骨架，按 [voice.md](references/voice.md) 重写口吻，「待人工确认」清单并入「待确认」。
• 已有定稿，需要口播：转交 `ray-kb`。
• 内容主体是别人的文章（翻译外文、转载中文）：进译介模式，完整执行 [translation.md](references/translation.md)。

知识库根目录不写死。优先使用用户明确路径，再向上查找 `.ray-obsidian.json` 或兼容目录结构；路径与文件职责见 [knowledge-pipeline.md](references/knowledge-pipeline.md)。

若找不到兼容知识库：

• 用户只要临时文章时，可以在当前工作区交付正文，并明确这次没有进入知识回流流程。
• 用户要完整内容管线、长期积累或 Obsidian 基础时，先转交 `ray-obsidian`，只确认一个关键问题：知识库要建在哪个本地目录。
• 不得自行创建 `~/rays-brain`，也不得把 Skill 安装目录当作用户知识库。

译介模式

内容主体是别人的文章时进这条支线，先读 [translation.md](references/translation.md)。译介的内容属于别人，所以本 Skill 的表达规则不适用于译文正文，只适用于 Ray 的译前引言和译后按语。顺序不能颠倒：

1. **授权**。先确认 `source_permission`。只有 `granted`（原作者明确许可）和 `open-license`（CC 等允许转载的许可）能往下走到平台草稿；`pending` 只做本地产物，`denied` 直接停。联系作者、确认许可、开公众号转载白名单都是用户动作，不代做，不把沉默当默许，也没有"合理使用"这一档。 2. **署名**。frontmatter 记录原标题、原作者、原文链接、发表日期和授权凭据；正文里另外要有读者真看得见的出处块。两边都在，检查器才放行。

翻译时按 `translation_mode` 区分：`full` 保留原文全部论点，Ray 的话只出现在译前引言和译后按语；`digest` 只译一部分并加入 Ray 的判断，但必须逐段分得开谁在说话。

**译文里的"我"永远是原作者的**，不得改写成 Ray 的经历。原文没有的事实不加，有的事实不改。

译文进 `<vault>/10-创作/30-文章草稿/`，`kind: translation` 或 `repost`；原文备份进 `<vault>/30-资料/`，不进 `<vault>/20-知识/`。交给 `ray-wechat` 时不勾选原创声明，交给 `ray-x-article` 时出处块随正文进编辑器。

写作流程

1. 建立最小写作任务

完整内容管线使用 `<vault>/50-系统/30-模板/内容成稿包.md`，开始写作前只要求填清：

• 目标读者和发布场景
• 读者读完后真正得到什么
• 一句话判断

材料已经足够时直接进入正文。

2. 找素材

读取本地原文、相关长期知识和既有调研；需要新闻、数据或引用时联网找。素材是弹药，不是许可：找不到证据的观点照样写，拿不准的地方进「待确认」。用到的链接和本地材料记在调研目录里，不在正文展示。

3. 连续写完全文

先读 [voice.md](references/voice.md) 和样本，然后从开头一口气写到结尾，再局部修句。不把提纲冒充文章。

面向公众号或 X 的长文要照顾手机阅读：用二级标题做阅读锚点，加粗关键问题和判断，Markdown 段落之间只留一个空行。

标题要让人想点开。内部可以生成多个候选，只向用户交付最适合的一版。

文末加 `## 待确认`，格式见 [voice.md](references/voice.md)。同时在 frontmatter 写 `publish_exclude_sections: 待确认`：这一节一直留在母稿里当记录，推送公众号或 X Article 时由 `ray-wechat`、`ray-x-article` 自动剔除，不用手动删。

4. 自修与终检

从读者角度连续读一遍，按 [quality-gates.md](references/quality-gates.md) 检查。重点是删掉正文里残留的自保话，把被写成资料综述的段落改回 Ray 在说话。

若已落盘，运行：

python3 scripts/article_check.py <文章路径>

脚本只查格式和篇幅。错误必须修改并重跑；提醒逐项判断，可以保留。`--profile` 只调篇幅档位，是旧文章原型的遗留参数，一般不用传。

5. 落盘与回流

• 成稿包进入 `<vault>/10-创作/20-写作任务/`。
• 调研和素材进入 `<vault>/30-资料/10-自主调研/<主题>/`。
• 当前草稿进入 `<vault>/10-创作/30-文章草稿/`。
• 公开发布是用户在平台上的动作；发布完成后走知识库的发布归档流程（`50-系统/40-自动化/发布归档/` 或工作台「登记发布」）写入 `<vault>/40-发布/`，不在本 Skill 内手工归档。
• 发布后，把新形成且值得长期复用的观点、案例或方法提炼回 `<vault>/20-知识/`。
• Ray 亲手改过、愿意发布的版本，加进 [voice.md](references/voice.md) 的样本清单。机器草稿不进清单。

6. 封面与平台交接

需要公众号、X 或 X Article 封面时转交 `ray-cover`，提供正文路径、成稿包路径和一句话判断。

用户明确要求把成稿送入 X Articles 后台时，把文章与 5:2 `x-article-cover` 交给 `ray-x-article`。它只保存并验证草稿，不自动发布。

用户明确要求公众号排版或保存草稿时，把文章、公众号封面和署名偏好交给 `ray-wechat`。它先生成本地预览，用户确认后才创建或更新公众号草稿。

交给平台前，Ray 要看过「待确认」里的每一条，并在正文里定下改还是留；这一节本身不用删，靠 `publish_exclude_sections: 待确认` 在推送时剔除。

用户要求把定稿变成口播视频时，把母稿和成稿包交给 `ray-kb`。

参考资料路由

• 每次写作都读 [voice.md](references/voice.md)。
• 终检时读 [quality-gates.md](references/quality-gates.md)。
• 翻译或转载别人的文章时读 [translation.md](references/translation.md)。
• 落盘或移动文件时读 [knowledge-pipeline.md](references/knowledge-pipeline.md)。

2026-09-22 之前的风格规则、质量闸门、文章原型和认可样本说明已归档到 rayskills 仓库 `docs/archive/2026-09-22-风格规则旧版/`，不再约束写作。

交付要求

交付文章链接、一句话核心判断和「待确认」里有几条。不要把内部检查过程写成长报告。