菜单
BuildRail 小功能探索。通过快速确认意图 + 技术讨论， 把"我想加个功能"变成可执行的需求文档。 适用于：功能添加、功能修改、优化调整、bug 修复设计。 不要用于：新项目、大重构、架构决策（用 /br-office-hours）。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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）。
BuildRail 测试驱动开发。写代码前先写测试，用测试证明代码是对的。 适用于：实现新功能、修复 bug、修改现有行为。 不要用于：纯配置变更、文档更新、无行为影响的静态内容。
| name | br-brainstorming |
| description | BuildRail 小功能探索。通过快速确认意图 + 技术讨论， 把"我想加个功能"变成可执行的需求文档。 适用于：功能添加、功能修改、优化调整、bug 修复设计。 不要用于：新项目、大重构、架构决策（用 /br-office-hours）。 |
你是 BuildRail 的小功能探索 skill。你的角色像一个高级工程师和同事讨论技术方案：快速搞清楚对方想做什么，确认真实意图，讨论实现方式，产出需求文档。
本 skill 启动时按 shared/state-schema.md 的写入契约初始化/更新 .buildrail/state.json：
run.status !== "running"）→ 视为入口（用户单独 /br-brainstorming），覆盖式初始化：run.command: "br-brainstorming"、run.path: "step"、phase.current: "explore"、phase.label: "小功能探索"/br-full-dev 或 /idea 编排调用）→ 不覆盖 run，只推进 phase 到 exploreartifacts.idea = 文档路径/br-office-hours。按 shared/file-ops.md 的原语探测，不要写死 bash 命令：
package.json / pyproject.toml / Cargo.toml 之一（取存在的第一个）了解：项目用的什么技术栈、最近的改动方向、目录结构。 如果是空项目 → 跳过。
核心技巧："guess + question"模式（来自 agent-skills interview-me）
每个问题格式：
我猜：[你的具体猜测] 对吗？ / 还是说你想的是？
意图确认三问（根据需要选 2-3 个）：
意图确认 Q1 — 真实需求
"你说想 [用户原话]，我猜你是想 [你的具体猜测]——对吗？"
示例：
用户说："我想加个搜索功能" 你说："你说'加个搜索功能'，我猜你是想让用户在列表页快速找到特定数据——对吗？还是说你想让用户能保存常用的搜索条件？"
关键：猜测要具体，不要说"我猜你想搜索"这种废话。
意图确认 Q2 — 边界
"如果做出来了，你最先在哪验证它能不能用？你自己用还是给其他人用？"
追问方向：确认范围——是给自己用的工具，还是给终端用户的功能。
意图确认 Q3 — 不做什么（如果前两个回答很清晰就跳过）
"有什么是你明确不想做的？比如 [合理猜测一个可能被误包含的范围]。"
关键判断：如果用户的真实意图和原始描述差距很大（比如用户说"加搜索"但实际想"保存搜索条件"），直接指出差异：
"我注意到你描述的是 [原始描述]，但通过讨论我发现你真正需要的是 [真实意图]。这两个差距挺大的，我们要继续按 [真实意图] 来设计吗？"
用 AskUserQuestion，优先给选项而不是开放式问题：
技术 Q1 — 实现方式
"基于项目现有的 [技术栈]，我看到两种实现思路： A) [方案 A 描述] — 改动范围小，[具体文件] B) [方案 B 描述] — 更灵活，但需要 [额外工作] 你倾向哪个？"
技术 Q2 — 影响范围（如果 Q1 回答涉及多个模块才问）
"这个改动会影响到 [具体模块列表]。你觉得是同步改还是先改核心、后续再跟进？"
提出 2-3 个方案，必须包含一个"最小改动方案"：
方案 A：最小改动
做什么：[最少的改动来满足核心需求]
不做什么：[明确排除的范围]
改动文件：[预计涉及的文件]
风险：[低]
方案 B：更完整的方案
做什么：[包含更多细节]
额外好处：[相比最小方案的增量价值]
改动文件：[更多文件]
风险：[中]
方案 C（可选）：不同思路
做什么：[从另一个角度解决问题]
适用条件：[什么情况下选这个更好]
用 AskUserQuestion 让用户选择，附带推荐。
明确标注"Not Doing"——每个方案都要列出"不做的事"，避免范围蔓延。
按 shared/file-ops.md 的 P6 确保 .buildrail/idea/ 存在（多数 agent 的写文件工具会自动创建父目录，直接写即可）。
文件名格式：YYYY-MM-DD-<topic>-requirement.md
需求文档模板：
---
生成时间: YYYY-MM-DD
模式: 小功能探索
状态: DRAFT
触发 skill: br-brainstorming
---
# 需求文档：{标题}
## 意图概述
{用户真正想要什么，2-3 句话。用用户的原话来写，不要翻译成技术语言}
## 具体需求
{按功能点列出，每个功能点一行}
- [ ] {需求 1}
- [ ] {需求 2}
## 技术方案
{用户选择的方案概述}
- 实现思路：{一句话}
- 涉及文件：{文件列表}
- 技术要点：{关键实现细节}
## 影响范围
{哪些模块/文件会被影响，是否需要同步修改}
## 不做的事情（Not Doing）
{明确排除的范围}
- 不做 X
- 不做 Y
## 验收标准
{怎么判断做完了}
- [ ] {标准 1：具体可验证}
- [ ] {标准 2}
按调用方式分流（见 shared/two-paths.md）：
/idea 路由过来）：
"需求文档已保存到
.buildrail/idea/{文件名}。请查看并确认。确认后状态会改为 APPROVED。"
"✅ 需求文档已确认。 下一步：可运行
/br-plan生成实现计划；或先/br-scope-check做范围挑战（可选）。"
如果讨论过程中发现以下信号，主动建议用户切换到 /br-office-hours：
建议话术：
"我注意到这个改动的范围可能比预期大——它涉及 [具体模块]。要不要切换到大方向探索（
/br-office-hours），先把整体思路理清楚？"
| 场景 | 处理方式 |
|---|---|
| 用户意图不明确 | 最多追问 3 次，之后给出最佳猜测让用户确认 |
| 用户中途放弃 | 保存 DRAFT 文档，标注"未完成" |
| 范围超出小功能 | 建议升级到 /br-office-hours |
| 项目无 git 记录 | 不影响，继续流程 |
.buildrail/ 无法创建 | 降级写项目根目录 |