菜单
BuildRail 大方向探索。以产品经理的视角深入审问项目方向， 通过结构化追问挖出真实需求，产出设计文档。 适用于：新项目、大重构、架构决策、产品方向讨论。 不要用于：具体功能添加、bug 修复、小改动（用 /br-brainstorming）。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| 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 个后需求仍不清晰 | 在文档的"开放问题"中列出未决事项，建议用户想清楚后再继续 |
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、修改现有行为。 不要用于：纯配置变更、文档更新、无行为影响的静态内容。