# Ray

> rayskills 工具箱的主入口与路由。当用户不确定该用哪个 ray-* skill、只是丢来一个真实任务/处境，或明确要求把一篇内容从 idea、调研、写作一路送到公众号草稿箱、X Articles 草稿箱或口播视频稿时，用本 skill 读取上下文，判断最该做的一步或执行已确认的内容生产链。也用于一轮工作完成后决定下一步。触发：/ray 或 /ray 后接任何真实任务描述。用户无需记住具体 skill 名；“推送到平台”“进入下一阶段”“走完整流程”都不构成公开发布授权，平台写入前按统一授权判定先做本地产物再确认。

- Skill: `imraywang/ray` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add imraywang/ray`
- Raw SKILL.md: https://api.skillmd.com/api/skills/imraywang/ray/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: imraywang (https://skillmd.com/u/imraywang)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/imraywang/ray

---


# ray:主入口与路由

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

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

## 怎么分发

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

## 工作台任务队列

知识工作台（ray-dashboard）会把用户排队的 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-writer` |
| 翻译外文文章或转载别人的中文文章 | `ray-writer`（译介模式，先过授权与署名两道门） |
| 从定稿长文提炼口播选题、逐字稿与拍摄提示 | `ray-kb` |
| 给定稿文章生成公众号、X 与 X Article 封面 | `ray-cover` |
| 给口播文稿或选题做拼贴 B-roll / 讲解片 | `ray-broll` |
| 把定稿文章排版并保存到微信公众号草稿箱 | `ray-wechat` |
| 把定稿文章和 5:2 封面保存到 X Articles 草稿箱 | `ray-x-article` |
| 从 idea/草稿一路做到文章、封面与 X Article 草稿 | [内容生产管线](references/content-pipeline.md) |

### 咨询 Consulting
| 用户想做的 | 分发到 |
|---|---|
| 评估企业能不能上知识库/AI(就绪度诊断) | `ray-consult`(诊断段) |
| 有了诊断结论,出方案蓝图/分期/报价 | `ray-consult`(方案段) |

### 协作 Orchestration
| 用户想做的 | 分发到 |
|---|---|
| 让 Grok / Claude / Codex 分工、独立复核、竞赛，或实时查 X / Reddit / 网页 | `ray-multimodel` |

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

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

- `ray-consult` 诊断段出了结论 → 通常直接进方案段;若结论是红灯,方案的 Phase 0 就是补齐前提。
- 用户没有兼容的本地知识库、但希望内容长期积累 → 先接 `ray-obsidian` 安全初始化，再把根目录和材料交给 `ray-writer`。
- `ray-writer` 完成并通过事实、语气与移动端可浏览性检查 → 接 `ray-cover` 生成平台封面；需要进入公众号草稿箱时接 `ray-wechat`，需要进入 X 后台时接 `ray-x-article`，两者默认只保存草稿。用户明确要求“走完整条管线”时按 [content-pipeline.md](references/content-pipeline.md) 连续执行。
- 已核验长文要做一次素材多次分发 → `ray-kb` 生成绑定母稿指纹的口播内容包；需要拼贴 B-roll 时再接 `ray-broll`。图片长文只在用户明确要求时进入后续视觉阶段。
- 清晰的大体量任务、关键复核或 X / Reddit / 网页实时调研 → 可接 `ray-multimodel`,由当前主控选择最小充分的外部通道并验收。

## 边界与纪律

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