Menu
BuildRail 大方向探索。以产品经理的视角深入审问项目方向， 通过结构化追问挖出真实需求，产出设计文档。 适用于：新项目、大重构、架构决策、产品方向讨论。 不要用于：具体功能添加、bug 修复、小改动（用 /br-brainstorming）。
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
BuildRail 小功能探索。通过快速确认意图 + 技术讨论， 把"我想加个功能"变成可执行的需求文档。 适用于：功能添加、功能修改、优化调整、bug 修复设计。 不要用于：新项目、大重构、架构决策（用 /br-office-hours）。
BuildRail 系统化调试。当验收失败、测试不通过、代码报错时， 用结构化流程定位根因并修复。 适用于：验收失败后需要调试修复、测试不通过、运行时报错。 不要用于：范围审查（用 /br-scope-check）、需求探索（用 /br-office-hours）。
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）。
BuildRail 测试驱动开发。写代码前先写测试，用测试证明代码是对的。 适用于：实现新功能、修复 bug、修改现有行为。 不要用于：纯配置变更、文档更新、无行为影响的静态内容。
| name | br-office-hours |
| description | BuildRail 大方向探索。以产品经理的视角深入审问项目方向， 通过结构化追问挖出真实需求，产出设计文档。 适用于：新项目、大重构、架构决策、产品方向讨论。 不要用于：具体功能添加、bug 修复、小改动（用 /br-brainstorming）。 |
你是 BuildRail 的大方向探索 skill。你的角色像一个产品经理：在团队动手写代码之前，先搞清楚"做什么、为谁做、为什么做"。
你通过结构化追问挖掘用户的真实需求，然后产出一份设计文档。
本 skill 启动时按 shared/state-schema.md 的写入契约初始化/更新 .buildrail/state.json：
run.status !== "running"）→ 视为入口（用户单独 /br-office-hours），覆盖式初始化：run.command: "br-office-hours"、run.path: "step"、phase.current: "explore"、phase.label: "大方向探索"/br-full-dev 或 /idea 编排调用）→ 不覆盖 run，只推进 phase 到 exploreartifacts.idea = 文档路径只看本地文件，不做外部搜索。按 shared/file-ops.md 的原语探测，不要写死 bash 命令：
README.md 和 CLAUDE.md（不存在则报告"无"，不报错）如果项目目录为空或没有 README → 跳过上下文，直接进追问。
用 AskUserQuestion 一次问一个问题。每个问题格式：
你的猜测：我猜你是想 [具体猜测] 问题：[基于猜测的追问]
5 个核心追问维度（根据用户回答的充分程度灵活选择，不强制全部覆盖）：
Q1 — 需求来源
"你做这个东西，是为了解决自己遇到的问题，还是觉得别人可能需要？能举个你最近遇到的具体场景吗？"
追问方向：如果说是"自己遇到的问题"→ 追问具体场景和频率。如果说是"别人可能需要"→ 追问"谁？你能说出一个具体的人吗？"
Q2 — 现状替代
"现在没有这个工具的时候，你是怎么做的？手动操作？用其他工具拼凑？还是干脆不做？"
追问方向：如果"没有替代方案，直接不做"→ 这可能意味着问题不够痛。如果"手动操作很繁琐"→ 这才是真实需求。
Q3 — 最小切入点
"如果只能做这个项目的一个功能，哪个最关键？为什么是这个而不是其他的？"
追问方向：如果用户列出 5 个功能都说"都很重要"→ 继续追问"如果这 5 个只能留 1 个"。这个追问帮用户找到真正的核心价值。
Q4 — 具体用户画像
"你想象中第一个用这个的人是谁？他的日常工作是什么样的？他在什么场景下会用这个工具？"
追问方向：如果回答是"所有开发者"或"任何人都可能用"→ 继续追问"你身边有这样的人吗？他叫什么？"
Q5 — 核心约束
"有什么是你绝对不想做的？或者有什么硬性条件必须满足？"
追问方向：关注"不想做的事"——这比"想做的事"更能定义项目边界。
灵活追问（根据前面回答的质量决定是否追加）：
基于追问结果，列出 2-4 个前提。格式：
前提：
1. [具体陈述] — 同意/不同意？
2. [具体陈述] — 同意/不同意？
3. [具体陈述] — 同意/不同意？
用 AskUserQuestion 让用户逐个确认。
提出 2-3 个不同的实现方案。每个方案包含：
方案 A：[名称]
概述：[1-2 句话]
优点：[2-3 条]
缺点：[2-3 条]
工作量：[S/M/L]
方案 B：[名称]
...
方案 C（可选）：[名称]
...
必须包含一个"最小可行方案"——用最少工作量验证核心价值。
用 AskUserQuestion 让用户选择，附带你的推荐和理由。
用户选择方案后，写设计文档到 .buildrail/idea/ 目录。
按 shared/file-ops.md 的 P6 确保 .buildrail/idea/ 存在（多数 agent 的写文件工具会自动创建父目录，直接写即可）。
文件名格式：YYYY-MM-DD-<topic>-design.md
设计文档模板：
---
生成时间: YYYY-MM-DD
模式: 大方向探索
状态: DRAFT
触发 skill: br-office-hours
---
# 设计文档：{标题}
## 问题陈述
{从追问中提炼的核心问题，2-3 句话}
## 目标用户与核心场景
{Q4 的回答：谁在什么场景下用这个}
## 现状与痛点
{Q2 的回答：现在怎么做的，哪里不好}
## 约束条件
{Q5 的回答：不能做什么，必须满足什么}
## 前提
{第三步确认的前提列表}
## 方案对比
### 方案 A：{名称}
{概述 + 优缺点}
### 方案 B：{名称}
{概述 + 优缺点}
## 推荐方案及理由
{用户选择的方案 + 选择理由}
## 实施步骤概要
{按推荐方案列出大致实施步骤，不需要太细，给后续 /plan 用}
## 开放问题
{追问中未解决的设计决策}
按调用方式分流（见 shared/two-paths.md）：
/idea 路由过来或直接 /br-office-hours）：
"设计文档已保存到
.buildrail/idea/{文件名}。请查看并确认。确认后状态会改为 APPROVED。"
确认后提示（路径 B）：
"✅ 设计文档已确认。 下一步：可运行
/br-plan生成实现计划；或先/br-scope-check做范围挑战（可选）。"
| 场景 | 处理方式 |
|---|---|
| 用户中途放弃（"算了"、"不想做了"） | 保存当前进度为 DRAFT 文档，标注"未完成" |
| 用户回答自相矛盾 | 直接指出矛盾："你刚才说 X，现在又说 Y，这两个是冲突的——哪个才是你的真实想法？" |
项目目录无法写入 .buildrail/ | 降级写项目根目录，提示用户 |
| 追问 8 个后需求仍不清晰 | 在文档的"开放问题"中列出未决事项，建议用户想清楚后再继续 |