brainstorm

brainstorm

通过与操作人员开放地来回讨论，将现有路线图条目的意图（以及已收集的研究资料）转化为具体的设计决策，并逐步写入该条目的 ## Design 部分。

判断类任务——描述并做出决策；不要编写脚本，不要写代码，也不要将工作拆分为任务（这是 plan 的职责，暂不处理）。

适用场景

• 操作人员运行 /jackin-dev:brainstorm <slug>，为一个尚未完成的路线图条目进行设计。

不适用场景

• 创建条目 → /jackin-dev:propose。
• 大规模外部或代码库调查 → /jackin-dev:research。
• 实施 → /goal Implement <slug>.md。

参数

• --research — 如果条目信息看起来不充分，先运行 /jackin-dev:research。
• --resume — 从当前的 ## Design 状态继续。

流程

1. 加载上下文。 阅读 docs/content/docs/roadmap/<slug>.mdx 中的 Problem、Why It Matters、Design-so-far、Related Files，以及已关联的任何研究资料。
2. 自由讨论。 开放地来回交流：提出备选方案、权衡取舍和待解决的问题。将 jackin' 设计原则和相关规则文件（ENGINEERING.md、HOST_AND_CONTAINER.md、TUI/文档规则）作为约束。尽量一次只问一个问题；每部分达成一致后，确认一下。
3. 逐步写入。 每个要点达成一致后，在 .mdx 的 ## Design 中追加或更新相应部分，记录决策及一句话的原因。--resume 会从此处继续。
4. 遇到未知事项？ 快速调查（Explore/grep 或 deep-research）。大规模调查 → 单独创建 /jackin-dev:research 研究档案，并在 ## Design 中链接。然后继续做决策。
5. 收敛方案。 当 ## Design 端到端涵盖整体方案后，总结并指出实施步骤（/goal Implement <slug>.md）。
6. 提交并推送。 每个已确定的部分都使用 docs: 提交（每次提交后推送）。

常见错误

• 编写代码或填充 ## Tasks——不在范围内。
• 不经来回讨论就直接写出完整设计，或一次提出许多问题。
• 只在聊天中记录决策，而不写入 ## Design（必须能够从中断处继续）。
• 重述规则文件的内容，而不是直接引用文件名。