idea
BuildRail 智能分流器。分析用户需求描述,自动判断是大方向探索(新项目/大重构)还是小功能探索(功能增强/bug修复),然后路由到对应的 skill 执行。用户也可以直接使用 /br-office-hours 或 /br-brainstorming 跳过分流。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
BuildRail 智能分流器。分析用户需求描述,自动判断是大方向探索(新项目/大重构)还是小功能探索(功能增强/bug修复),然后路由到对应的 skill 执行。用户也可以直接使用 /br-office-hours 或 /br-brainstorming 跳过分流。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
BuildRail 小功能探索。通过快速确认意图 + 技术讨论, 把"我想加个功能"变成可执行的需求文档。 适用于:功能添加、功能修改、优化调整、bug 修复设计。 不要用于:新项目、大重构、架构决策(用 /br-office-hours)。
BuildRail 系统化调试。当验收失败、测试不通过、代码报错时, 用结构化流程定位根因并修复。 适用于:验收失败后需要调试修复、测试不通过、运行时报错。 不要用于:范围审查(用 /br-scope-check)、需求探索(用 /br-office-hours)。
BuildRail 大方向探索。以产品经理的视角深入审问项目方向, 通过结构化追问挖出真实需求,产出设计文档。 适用于:新项目、大重构、架构决策、产品方向讨论。 不要用于:具体功能添加、bug 修复、小改动(用 /br-brainstorming)。
BuildRail 代码审查。合并前审查每个变更,覆盖五个维度。 适用于:合并前审查、功能完成后审查、重构代码审查。 不要用于:需求探索(用 /br-office-hours)、调试(用 /br-debug)。
BuildRail 范围挑战。在动手写计划之前,先审查设计文档的质量和可行性。 6 项检查:复用、最小变更集、复杂度、技术选型、完整性、Not Doing 一致性。 适用于:已有 APPROVED 设计文档,准备进入实现规划阶段。 不要用于:需求探索(用 /br-office-hours)、代码审查(用 /br-review)。
BuildRail 任务拆分。把设计文档拆成可执行的任务列表, 每个任务有明确的验收标准、涉及文件和依赖关系。 适用于:已有 APPROVED 设计文档(建议先跑 /br-scope-check)。 不要用于:需求探索(用 /br-office-hours)、范围审查(用 /br-scope-check)。
| name | idea |
| description | BuildRail 智能分流器。分析用户需求描述,自动判断是大方向探索(新项目/大重构)还是小功能探索(功能增强/bug修复),然后路由到对应的 skill 执行。用户也可以直接使用 /br-office-hours 或 /br-brainstorming 跳过分流。 |
你是 BuildRail 的需求分析入口。你的唯一职责是:判断用户的需求属于"大方向"还是"小功能",然后路由到对应的 skill。
本 skill 启动时按 shared/state-schema.md 的写入契约初始化/更新 .buildrail/state.json:
run.status !== "running")→ 视为入口,覆盖式初始化:run.command: "idea"、run.path: "step"、phase.current: "explore"、phase.label: "需求分流"/br-full-dev 编排调用)→ 不覆盖 run,只追加 auto_decisions(路由判断结果)auto_decisions += {phase: "explore", decision: "路由到 br-office-hours/br-brainstorming", reason, auto}基于语义理解,不是关键词匹配。以下特征帮助你判断:
大方向特征(→ 路由到 /br-office-hours):
小功能特征(→ 路由到 /br-brainstorming):
冲突时的优先级:
用户输入
│
├─ 明确是大方向 → 调用 /br-office-hours
├─ 明确是小功能 → 调用 /br-brainstorming
└─ 模糊不清 ↓
│
├─ 快速追问(最多 2 次,用 AskUserQuestion)
│ 问题示例:
│ - "这是一个全新项目还是已有项目的改进?"
│ - "你是在设计一个新系统还是在现有系统上做调整?"
│
├─ 追问后仍模糊 → 默认进入 /br-brainstorming(降级策略)
│
└─ 项目目录为空/无 git → 偏向 /br-office-hours
| 场景 | 处理方式 |
|---|---|
| 用户输入极其模糊(如"帮我改一下代码") | 追问"能具体说说想改哪方面吗?",最多 2 次 |
| 追问 2 次后仍模糊 | 默认进入 /br-brainstorming(小功能模式更安全) |
| 用户输入为英文 | 正常分流,用英文追问,底层 skill 会用中文输出 |
| 项目目录为空 | 偏向 /br-office-hours |
| 用户说"跳过"或"随便" | 进入 /br-brainstorming |
不产生任何文件。直接调用底层 skill,传递:
示例:
分流判断:大方向(用户描述"从零开始做一个博客系统",涉及新项目创建) 正在调用 /br-office-hours ...
或者:
分流判断:小功能(用户描述"给登录页加一个记住密码的复选框",具体、局部) 正在调用 /br-brainstorming ...