Menü
BuildRail 智能分流器。分析用户需求描述，自动判断是大方向探索（新项目/大重构）还是小功能探索（功能增强/bug修复），然后路由到对应的 skill 执行。用户也可以直接使用 /br-office-hours 或 /br-brainstorming 跳过分流。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| 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 ...
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）。