القائمة
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/ 无法创建 | 降级写项目根目录 |