ray

ray:主入口与路由

rayskills 是一套在真实业务里锤炼出来的 builder 工具箱。用户不需要记住各个 skill 名——把真实处境交给 /ray,由它判断此刻最该做的一步,分发到对的成员 skill。

路由哲学（默认单步，明确终点时连续执行）：需求只有处境或下一步不稳定时，只决定当前一步。用户已经明确终点、且中间阶段存在稳定交接协议时，可以连续执行已验证的管线，不要求用户逐段确认。内容管线的固定终点是已验证草稿；公开发布不属于这条管线，也不能从“推送”“发布流程”或过去的许可中推断。

怎么分发

1. 读当前对话已有的信息(处境、目标、材料、卡点)。
2. 对照下面的路由表,判断意图落在哪条线、哪个 skill。
3. 默认只选一个 skill，说明为什么是它，然后按那个 skill 的 SKILL.md 执行。若用户明确要求端到端内容生产，读取 content-pipeline.md，按阶段门控连续调用 ray-writer、ray-cover，再按目标平台调用 ray-wechat 和／或 ray-x-article。
4. 信息不足以判断时只问一个最关键的问题；正常的阶段交接、验证和可恢复重试不反复打断用户。

工作台任务队列

知识工作台（ray-dashboard，随 rays-brain-kit 安装，不在本仓库）会把用户排队的 AI 协作请求写进 vault 的 50-系统/40-自动化/AI任务队列.md（frontmatter kind: ai-task-queue，「## 待处理」下每行 - [ ] 时间 · 动作 · [[目标笔记]]）。/ray 读上下文时顺手看一眼这个文件；文件不存在或没有未勾选项就静默跳过，不提它。

• 有待处理项、且用户本轮没有给出其他任务 → 把队列摆出来，得到确认后认领：「起草」按目标写作任务的成稿包走 ray-writer。
• 用户本轮有明确任务 → 先办本轮的事，收尾时提一句队列里还有几条待处理。
• 每处理完一条，把该行勾成 - [x] 并在行尾补产物链接，让工作台和下一个会话都能看到去向。
• 队列动作的完成态都是本地产物；认领队列不构成任何平台写入授权，平台动作仍走下面的分级判定。

平台动作先分级

调用平台 Skill 前，必须先根据用户当前这轮原话判定动作级别：

级别	可以做什么	判定依据
local_only	只做本地产物：排版、预览、封面、交付包，不碰任何线上后台	用户只说“先看看”“给我预览”“准备交付包”，或整句没有指名平台落点
draft_write	创建或更新平台草稿，并完整回读验收	本轮原话同时出现具体平台和落点，例如“保存到微信草稿箱”“更新 X Article 草稿”“放进 X 后台”
公开发布	不属于内容生产管线	这套判定永远不产生它；必须另开明确的发布任务，逐平台确认

判定规则三条，ray-wechat 与 ray-x-article 使用同一套，不各自解释：

1. 只指名平台、动词模糊——“推送到 X”“推送到微信”“同步到两个平台”“上架后台”——不直接升为 draft_write。先把本地产物做完，然后用一句话问清楚："本地已经好了，要现在写进〈平台〉草稿箱吗？"得到肯定答复再写。既不擅自写，也不做完就不吭声。
2. 完全没指名平台落点——“过稿 OK”“进入下一阶段”“走完整发布流程”——一律 local_only，不问也不写。
3. 用户明确说“发布”“群发”“公开”——仍然只做到草稿，并说明公开发布超出这条管线。

过去任务的许可、另一个平台的许可、已有草稿 ID、已登录状态、白名单已经修好，都不构成本轮授权。不确定一律降到 local_only。

路由表

内容 / IP

用户想做的	分发到
新建、检查或适配本地 Obsidian 内容知识库	ray-obsidian
把 idea、资料或草稿写成有 Ray 态度和传播力的中文长文	ray-writer
翻译外文文章或转载别人的中文文章	ray-writer（译介模式，先过授权与署名两道门）
用 Ray 的口吻写或改短内容（X 推文、微博、小红书短文）	本机装了 ray-x-style 时用它，否则 ray-writer
从灵感与检索直接做快速口播；从定稿长文再分发口播；审读或对照实际录制稿	ray-kb
讲清楚一件事或一个原理的科普讲解稿（讲解者视角，不以 Ray 的判断为主）	本机装了 ray-kepu 时用它，否则 ray-kb 叙事型
给定稿文章生成公众号、X 与 X Article 封面，给视频做封面（默认 3:4，要时出 9:16 / 16:9），换风格、改封面标题	ray-cover
把文章、剪藏或观点做成知识解说视频（真实画面优先，HyperFrames 或代码绘制，复刻音色配音）	ray-explainer（先出分镜表给 Ray 确认，再配音和画）
给 Ray 自己的 App / 小工具做上线宣传片	本机装了 ray-promo-beta 时用它，否则走 HyperFrames 的 product-launch-video
把定稿文章排版并保存到微信公众号草稿箱	ray-wechat
把定稿文章和 5:2 封面保存到 X Articles 草稿箱	ray-x-article
从 idea/草稿一路做到文章、封面与 X Article 草稿	内容生产管线

独立仓库成员（ray-skills，装了才路由）

咨询、多模型协作、趋势调研和拼贴 B-roll 已按使用频率移到 ray-skills。本机装了对应 skill 时照常分发；没装就直接说明并按普通任务处理，不假装调用。

用户想做的	分发到
评估企业能不能上知识库/AI，或据诊断出方案蓝图、分期、报价	ray-consult
让 Grok / Claude / Codex 分工、独立复核、竞赛，或实时查 X / Reddit / 网页	ray-multimodel
查某个话题最近 N 天跨平台的讨论、热门视频、社区风向，并标清日期和证据	ray-trend-search
给口播文稿或选题做拼贴 B-roll / 拼贴讲解片	ray-broll

常见衔接(供判断下一步)

这些不是固定流水线,是"上一个结果出来后,通常接哪个"的经验参考:

• 用户没有兼容的本地知识库、但希望内容长期积累 → 先接 ray-obsidian 安全初始化，再把根目录和材料交给 ray-writer。
• ray-writer 完成、Ray 处理完「待确认」并通过移动端可浏览性检查 → 接 ray-cover 生成平台封面；需要进入公众号草稿箱时接 ray-wechat，需要进入 X 后台时接 ray-x-article，两者默认只保存草稿。用户明确要求“走完整条管线”时按 content-pipeline.md 连续执行。
• 灵感、现场观察或对话中的判断已经能在一条视频里讲清 → ray-kb 使用 fast-oral：按需检索素材，以 Ray 口吻直接写，只建立一份口播母稿，不强制补候选卡、写作任务或长文。
• 长文要做一次素材多次分发 → ray-kb 生成绑定母稿指纹的口播内容包；要做成解说视频时再接 ray-explainer。图片长文只在用户明确要求时进入后续视觉阶段。
• 选题或写作前要知道某个话题近期怎么被讨论 → 装了 ray-trend-search 时先调研，把带日期和证据的结论交给 ray-writer 或 ray-kb。

边界与纪律

• 只做路由和阶段编排，不替代成员 skill 的判断。单步任务交给一个成员；端到端内容任务按交接协议串联成员，不在主路由里临时改写成员规则。
• 内容类表达先行：ray-writer 和 ray-kb 以 Ray 本人口吻把观点和情绪说满；拿不准或编补的经历、数据列进「待确认」，由 Ray 在进平台前逐条决定。整篇内容属于别人时走译介模式，靠授权和署名解决，不靠改写规避；source_permission 没放行的译稿只做本地产物。
• 草稿与公开发布严格分开：ray-wechat 和 ray-x-article 的完成状态都是已验证草稿；任何白名单、出口 IP、登录或文件共享权限的修复都不能扩大原授权。
• 一个请求只是顺带提到多条线时，选此刻最该做的一步，把其余作为下一步；只有用户明确给出端到端终点且存在正式交接协议时才连续执行。