Menu
在任何需要改代码的需求进入开发链之前做一次轻量分诊，按改动性质判定 L1/L2/L3 车道，决定走快车道还是全链，并把后续交接给对应 skill。本 skill 不产出文档，只给出"车道结论 + 下一站"。属于整条「需求 → 交付」链的入口前置站。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
契约治理三件套的「值层」。核对同一个物理契约值（MQ topic/group、OSS bucket、消息字段名/别名、内部 HTTP 路径等）在 .env/.env.example/代码生效点/Java 对端多处是否逐字相等，找出配置漂移与死值，防止消息收不到/文件取不到。本 skill 只比对「同一个值在多处是否一致」，不判断结构/语义是否破坏对端（那是结构层，转 contract-guard），也不改文档。
指导 LLM 如何使用 toLink-Rag 项目的 MQ 消息中台进行消息收发、定义新消息类型以及处理多厂商适配逻辑。
当用户认为当前模块代码实现完毕，且当前分支应为 dev，需要从 dev 基于当前修改创建规范分支、提交并发起合并到 dev 的 GitHub PR 时使用；也用于发布收口，即直接创建 dev -> master 的 release PR，不新建 release 分支。适用于“从 dev 新建分支”“把当前修改提 PR”“实现完成创建 feature/refactor 分支并 PR”“发布新版本”“dev 合并 master”等交付收口场景。本 skill 是交付链终点，并在建分支/提 PR 前执行收口门槛：测试未过、契约文档失同步、acceptance 未提升者拒绝收口。
当用户要求把需求、功能、技术方案、架构改造、故障复盘、项目治理实践或实现过程写成博客/技术文章时必须使用；尤其适用于“写一篇博客”“生成技术博客”“把这个需求写成文章”“根据这个功能写博客”“把项目实现讲清楚”等请求。使用时要基于用户给出的需求和 toLink-Rag 当前仓库的真实代码、文档、契约、配置与测试证据完成分析，默认输出 Markdown 到 `.specs/blog/《博客名称》.md`。文章须采用「少量
把项目里已有的内部组件（如 MQ 中台、解析 pipeline、缓存层、对象存储）抽象成一份「项目自有 skill」，让 AI 每次接入都自动复用该组件的架构边界与约定。读组件真实代码，提炼「架构定位 / 职责边界 / 已落地清单 / 扩展点 / 红线」五要素，按统一原型生成 SKILL.md，登记到 .ai/skills/README.md 注册表并跑校验。
当用户要提 issue、登记 bug、记录新需求时使用；自动识别所属项目，生成结构化 issue 内容，先在 Linear 建主记录、再在 GitHub 建镜像，并双向回链。用户说"提个 issue""记一下这个 bug""把这个需求登记一下""同步到 Linear 和 GitHub""别再依赖 Linear 自动同步"时都应触发，即使没有明确说出"Linear"或"GitHub"。
| name | flow-router |
| description | 在任何需要改代码的需求进入开发链之前做一次轻量分诊，按改动性质判定 L1/L2/L3 车道，决定走快车道还是全链，并把后续交接给对应 skill。本 skill 不产出文档，只给出"车道结论 + 下一站"。属于整条「需求 → 交付」链的入口前置站。 |
| when_to_use | 当用户提出任何需要改代码的需求、想法或修改请求，且尚未确定该走快车道还是全套流程时，先用本 skill 做分诊。触发示例：'要改个东西'、'加个字段'、'实现这个需求'、'帮我做个功能'、'这个改动走什么流程'。判为 L1 → 直接转 implementation-execution；判为 L2/L3 → 转 brief-generator（在其中按车道决定 brief 详略与是否要 technical-design）。若用户已经明确在写 brief / acceptance / 技术方案 / 编码，说明车道已定，不必再回本站。 |
本 skill 是「需求 → 交付」链的入口前置站。它解决一个老问题：以前复杂度判断埋在第 4 站（implementation-execution）内部，等于排到了用不上的位置——一个加字段的小改动也要先写 brief、再写 acceptance、再写方案。
本站把复杂度判断提到入口：进来先分诊，按改动性质选车道，小改动不再走全套。
本 skill 不产出任何文档。它的输出是一个车道结论 + 推荐下一站，然后把控制权交给对应 skill。
按改动性质三选一。判定从严：只要命中任一更高车道的信号，就升到更高车道，不因"看起来小"往下压级。
| 车道 | 判据 | 走的链 |
|---|---|---|
| L1 快车道 | 单文件 / 配置 / 文案 / 小修，无契约变更 | implementation-execution → run-all-tests → branch-pr-workflow |
| L2 标准 | 单模块功能，契约小变 | brief-generator（轻量）→ implementation-execution → run-all-tests → code-review-and-quality → branch-pr-workflow，跳过独立 technical-design |
| L3 全链 | 跨模块 / 契约 / 中间件 / 数据迁移 | 现有完整链：brief → acceptance → technical-design → impl → test → review → PR |
只要改动触碰下列任一处，一律判 L3，不得归入 L1/L2——因为这些都受 CLAUDE.md 第六节的机器强制同步规则约束，失同步会引发跨服务集成事故：
src/models/ 下的 ORM 模型（牵动 schema + 迁移 + docs/api/schemas/mysql.md）src/core/mq/messages/ 下的消息契约（牵动 docs/api/mq_contracts.md + docs/internals/mq.md）migrations/ 下的数据迁移src/core/pipeline/parse_task/ 的状态机 / 终态语义这条规则把「车道分级」和「机器强制门槛」绑在一起：契约改动不可能被误判成快车道。
判定不确定时就高不就低，并说明依据。
输出固定包含：
implementation-execution（直接编码，无需 brief）brief-generator（轻量 brief，跳过 technical-design）brief-generator（完整链起点）implementation-execution → run-all-tests → branch-pr-workflowbrief-generator（L2 轻量、跳 TD；L3 走完整链）