Menú
在任何需要改代码的需求进入开发链之前做一次轻量分诊，按改动性质判定 L1/L2/L3 车道，决定走快车道还是全链，并把后续交接给对应 skill。本 skill 不产出文档，只给出"车道结论 + 下一站"。属于整条「需求 → 交付」链的入口前置站。
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
契约治理三件套的「值层」。核对同一个物理契约值（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 走完整链）