菜单
把灵感、剪藏审核卡、调研包、长期知识或已有草稿装配成有事实、有情绪、有网感和传播力的中文长文，并接入用户本地 Obsidian 知识库的成稿包、调研、草稿、发布与复盘流程。用于用户说“把这个 idea 写成文章”“从这条资料发展成长文”“写一篇公众号或 X 长文”“检查或重写这篇文章”“把内容生产流水化”时；找不到兼容知识库时先转交 ray-obsidian 建立或适配。不得虚构用户经历、数据、现场或情绪，不自动发布，也不使用 WeWrite。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
把口播文稿、观点句或一个完整选题做成编辑隐喻拼贴风格的视频（黑白半调剪贴 + 平坦色场 + 从空场逐件组装的定格动画）。两种模式：单句 5 秒 B-roll（单条或批量），以及 beat map 驱动的 45–60 秒完整讲解片（含旁白 TTS、内容感知变速、字幕与拼装）。用户说“拼贴 b-roll”“纸拼贴视频”“vox 那种风格的视频”“半调拼贴动画”“给这句口播配画面”“把这个选题做成拼贴讲解视频”时使用；也承接 ray-writer / ray-cover 产出后的视频化下游需求。不用于：需要精确图层与时间线控制（转 HyperFrames）、只要提示词不要成片、真人口播或产品实拍广告。
把已经定稿的中文长文排成适合手机浏览的微信公众号富文本，生成可复制预览，在用户确认后创建或更新公众号草稿，并回读核对标题、封面、正文、空段落、署名和中文编码。用于“给公众号重新排版”“把这篇推到微信公众号草稿箱”“更新已有微信草稿”“公众号排版太单调或有多余空行”“恢复失败的草稿更新”时。优先更新文章 frontmatter 记录的原草稿，不制造同题重复草稿；未经明确授权只做到预览，不发布文章。
rayskills 工具箱的主入口与路由。当用户不确定该用哪个 ray-* skill、只是丢来一个真实任务/处境，或明确要求把一篇内容从 idea、调研、写作、封面一路送到公众号或 X Articles 草稿箱时，用本 skill 读取上下文，判断最该做的一步或执行已确认的内容生产链。也用于一轮工作完成后决定下一步。触发：/ray 或 /ray 后接任何真实任务描述。用户无需记住具体 skill 名。
把已经确定核心判断的文章、成稿包或长文转成公众号、普通 X 分享图与 X Articles 后台封面。提炼一个可一眼读懂的视觉隐喻，在 Ray 的编辑视觉体系中选择复古现代主义、极简隐喻、安静油墨、编辑隐喻拼贴或工具桥接方向，先生成无字底图，再用确定性排版写入准确中文标题，并输出各平台文件、提示词和清单。用于“给这篇文章做封面”“公众号和 X 都要封面”“做 5:2 Article 封面”“用 Adrian 或 Vox 那类风格”“把内容生产接上封面管线”时；不用于正文写作、自动发布或完整解说视频。
在用户本地新建、检查或渐进适配一个面向长期知识与内容生产的 Obsidian 知识库，复用 Ray 的资料、知识、灵感、成稿包、调研、草稿、发布与回流分层。用于“帮我搭一个 Obsidian 知识库”“给 ray-writer 准备本地知识库”“把现有 vault 接入内容生产管线”“检查知识库结构是否完整”时；也在 ray-writer 找不到兼容知识库时使用。只补缺失结构，不覆盖、移动或删除用户已有笔记，不强制安装插件、同步服务或 Git。
生成长文 / 深度报告 / 数据型内容,三格式协同产出——交互式 HTML(magazine 杂志排版,含 Tab/Quiz/Chart.js/Timeline 组件)、A4 PDF(headless Chrome 渲染)、公众号 markdown(长句叙事)。采用精修的编辑设计语言(衬线中文标题、锈红点缀、纸张颗粒、drop cap、装饰分隔、等宽数字),读起来像真正的杂志文章而非 SaaS dashboard。当用户要做长篇分析、白皮书、深度报告、多段数据型长文,或说「做一个报告」「深度分析」「长文章」「报告版」「PDF 报告」「html version」「pdf report」,或丢来一份提纲期待成品时使用;格式没点名也默认走 HTML,再 offer PDF+公众号。不用于短文、dashboard、UI 组件、或公众号自动发布流程(那用 wewrite)。触发 /ray-report
| name | ray-writer |
| description | 把灵感、剪藏审核卡、调研包、长期知识或已有草稿装配成有事实、有情绪、有网感和传播力的中文长文，并接入用户本地 Obsidian 知识库的成稿包、调研、草稿、发布与复盘流程。用于用户说“把这个 idea 写成文章”“从这条资料发展成长文”“写一篇公众号或 X 长文”“检查或重写这篇文章”“把内容生产流水化”时；找不到兼容知识库时先转交 ray-obsidian 建立或适配。不得虚构用户经历、数据、现场或情绪，不自动发布，也不使用 WeWrite。 |
把写作当成一条可追溯的生产线。先装配事实、判断和情绪，再写文章；先验证，再交付。
知识库根目录不写死。优先使用用户明确路径，再向上查找 .ray-obsidian.json 或兼容目录结构；路径与文件职责见 knowledge-pipeline.md。
若找不到兼容知识库：
ray-obsidian，只确认一个关键问题：知识库要建在哪个本地目录。初始化检查通过后再继续写作。~/rays-brain，也不得把 Skill 安装目录当作用户知识库。使用 <vault>/50-系统/30-模板/内容成稿包.md。至少填清：
不要因为模板有空位而编造内容。核心判断不清时，先从材料中提出一个最有张力的候选并明确标注待用户确认。
优先读取本地原文、相关长期知识和既有调研。需要最新信息、精确引用或来源网页时再联网核对。
为关键内容分别记录：
数字、日期、产品状态、人物职位、政策和公开指标必须逐项核对。保留原始链接和本地材料入口。
阅读 article-prototypes.md，只选择一个主原型。其他原型只能作为局部手法。
原型决定结构自由度：观点和现象解读可以连续推进；个人实践依赖真实过程；案例拆解需要机制与边界；教程必须保留清楚的小标题和可执行步骤。
写作前明确：
传播句必须承担观点，不做脱离正文的空金句。网感来自当下语境、自然口语、反问、对比和节奏，不来自流行词堆砌。
写作前阅读 voice.md。先完成全文，再局部修句，不把提纲冒充文章。
面向公众号或 X 的长文还必须设计浏览节奏：
标题至少同时满足清楚、张力和可信。内部可以生成多个候选，但只向用户交付最适合的一版。
完整执行 quality-gates.md：
若已落盘，运行：
python3 scripts/article_check.py <文章路径>
检查失败就修改并重跑。机械检查通过不等于文章合格，四层人工审读仍然必须完成。
<vault>/10-创作/10-灵感/20-成稿包/。<vault>/30-资料/10-自主调研/<主题>/。<vault>/10-创作/20-草稿/。<vault>/40-发布/ 对应目录。<vault>/20-知识/。文章核心判断、标题和情绪曲线通过检查后，需要公众号或 X 封面时转交 ray-cover。向它提供正文路径、成稿包路径、一句话判断、核心冲突句和传播句；不要只传标题。
ray-cover 负责从同一视觉母题生成无字底图，再分别排成公众号与 X 封面。写作阶段不让图片风格反过来改动事实和核心判断。若还需要约 5 秒竖屏动态素材，由 ray-cover 继续转交 gbro-collage-broll。
用户明确要求把成稿送入 X Articles 后台时，再把通过检查的文章与 5:2 x-article-cover 交给 ray-x-article。它只保存并验证草稿，不自动发布。
用户明确要求公众号排版或保存草稿时，把通过检查的文章、公众号封面和署名偏好交给 ray-wechat。它先生成并验证本地预览，用户确认后才创建或更新公众号草稿；不要在 ray-writer 内临时拼 HTML 或直接调用微信接口。
风格只从用户明确认可、亲自修改或正式发布的内容中学习。普通机器草稿不得自动成为新样本。
ray-cover，不要在本 Skill 内临时拼提示词。ray-wechat；写作阶段不承担排版主题和微信接口逻辑。向用户交付完整文章链接、事实清单链接和一句话核心判断。简要说明已核对哪些关键事实、是否存在仍需用户提供的个人材料。不要把内部检查过程写成长报告。