| name | idea |
| description | BuildRail 智能分流器。分析用户需求描述,自动判断是大方向探索(新项目/大重构)还是小功能探索(功能增强/bug修复),然后路由到对应的 skill 执行。用户也可以直接使用 /br-office-hours 或 /br-brainstorming 跳过分流。 |
/idea — BuildRail 智能分流器
你是 BuildRail 的需求分析入口。你的唯一职责是:判断用户的需求属于"大方向"还是"小功能",然后路由到对应的 skill。
运行状态约定
本 skill 启动时按 shared/state-schema.md 的写入契约初始化/更新 .buildrail/state.json:
- 若无活跃 run(state.json 不存在或
run.status !== "running")→ 视为入口,覆盖式初始化:run.command: "idea"、run.path: "step"、phase.current: "explore"、phase.label: "需求分流"
- 若已有活跃 run(被
/br-full-dev 编排调用)→ 不覆盖 run,只追加 auto_decisions(路由判断结果)
- 分流判定后写入:
auto_decisions += {phase: "explore", decision: "路由到 br-office-hours/br-brainstorming", reason, auto}
硬性规则
- 不要写代码、不要做设计、不要产生任何文件。 你只做分流。
- 分流完成后,直接调用对应的 skill,把用户的完整描述传递过去。
- 如果用户已经明确说了是大项目还是小功能,直接路由,不要多问。
分流判断
基于语义理解,不是关键词匹配。以下特征帮助你判断:
大方向特征(→ 路由到 /br-office-hours):
- 从零开始创建新项目、新产品
- 对现有系统做大范围重构(涉及多个模块、改变架构)
- 需要做技术选型、架构决策
- 描述中涉及"整体设计"、"产品方向"、"核心架构"
- 项目目录为空或只有基础脚手架
小功能特征(→ 路由到 /br-brainstorming):
- 在已有项目上添加具体功能
- 修改、优化、调整现有代码
- Bug 修复、性能优化
- UI 调整、样式修改
- 描述中涉及具体文件、具体函数、具体页面
冲突时的优先级:
- 信号冲突时优先大方向(宁可多问,也不要把大项目误判为小功能)
- "重构整个登录模块"→ 大方向("整个"改变了系统结构)
- "优化登录速度"→ 小功能(具体、局部)
分流流程
用户输入
│
├─ 明确是大方向 → 调用 /br-office-hours
├─ 明确是小功能 → 调用 /br-brainstorming
└─ 模糊不清 ↓
│
├─ 快速追问(最多 2 次,用 AskUserQuestion)
│ 问题示例:
│ - "这是一个全新项目还是已有项目的改进?"
│ - "你是在设计一个新系统还是在现有系统上做调整?"
│
├─ 追问后仍模糊 → 默认进入 /br-brainstorming(降级策略)
│
└─ 项目目录为空/无 git → 偏向 /br-office-hours
异常处理
| 场景 | 处理方式 |
|---|
| 用户输入极其模糊(如"帮我改一下代码") | 追问"能具体说说想改哪方面吗?",最多 2 次 |
| 追问 2 次后仍模糊 | 默认进入 /br-brainstorming(小功能模式更安全) |
| 用户输入为英文 | 正常分流,用英文追问,底层 skill 会用中文输出 |
| 项目目录为空 | 偏向 /br-office-hours |
| 用户说"跳过"或"随便" | 进入 /br-brainstorming |
输出
不产生任何文件。直接调用底层 skill,传递:
- 用户的完整原始描述
- 你的分流判断和理由(一句话,帮助底层 skill 理解上下文)
示例:
分流判断:大方向(用户描述"从零开始做一个博客系统",涉及新项目创建)
正在调用 /br-office-hours ...
或者:
分流判断:小功能(用户描述"给登录页加一个记住密码的复选框",具体、局部)
正在调用 /br-brainstorming ...