创造性思维
使用 Tim Hurson 的创造性思维模型引导一个结构化的设计环节，之后可以选择将其撰写为 RFC。
输入
$ARGUMENTS
- 如果输入以
rfc开头，则运行 RFC 模式。其后面的任何内容均为可选标题或输出路径。 - 否则运行 交互模式，将输入视为问题陈述。如果为空，则在执行任何操作之前，请用户用一两句话描述问题。
如何引导
- 将所有内容扎根于代码。 在每一步之前，搜索并读取与之相关的文件、模式、配置和文档，并在依赖它们时引用路径。此环节相对于白板讨论的价值在于，结论建立在系统的实际行为之上，因此需要验证而不是假设。对于跨多个文件的广泛扫描，委托给 Explore 子代理，以便环节的上下文保持集中在讨论上。
- 保持用户负担较轻。 每轮最多问 5 个问题，并根据你找到的内容附上自己的建议答案，这样用户可以回答“是的，基本如此，但是……”而不是从空白开始。
- 每轮一步。 用类似
步骤 2/6 — 什么是成功？的标题开始每一步，完成该步然后等待。只有在用户准备好时才继续；允许他们跳过、重新访问或在步骤之间跳转。 - 维护一个运行笔记文件。 每步之后，将达成一致的结果追加到
<rfc-dir>/<slug>.notes.md（按 RFC 模式第 3 步中描述的选择<rfc-dir>）。长时间讨论会被压缩或稍后恢复；笔记文件使得 RFC 模式或新的讨论能够继续而不会丢失决策。第一次创建时告知用户其位置。
六步
1. 发生了什么？
目标：对当前现实和目标未来达成共识。 探索受影响区域的现有实现、调用点、数据模型和最近的 git 历史。 涵盖：痛点或瓶颈（附带证据，如错误、指标或代码）、受影响的模块和服务、受影响的人员，以及“解决”后的样子。
2. 什么是成功？（DRIVE）
目标：每个选项都将被评估的标准。从第 1 步提出一个草案，让用户修正。
- Do（必须做）：解决方案必须完成什么
- Restrictions（限制）：硬约束（向后兼容、性能预算、技术栈、合规性）
- Investment（投入）：团队愿意花费的时间、人力和复杂性
- Values（价值）：打破平局的工程原则（简单性、可测试性……）
- Essential outcomes（关键结果）：不可协商的结果，尽量可衡量
还要明确记录非目标。
3. 问题是什么？
提出 2–3 个以不同方式框定挑战的“我们如何能够……”问题，例如一个狭窄的，另一个挑战第 1 步中某个假设的。用户选择或重写一个；它成为剩下讨论的问题陈述。
4. 生成答案
提出 2–3 个基于代码库的真正不同的方法，而不是一个想法的变体。对于每个方法：简要草图、它涉及的文件或模块、以及其主要风险。在这一步中暂不判断，并邀请用户提出自己的想法。
5. 锻造解决方案
根据 DRIVE 对每个方法进行评分（小表格效果不错），推荐一个，并说明你接受的权衡。然后加固它：故障模式、边界情况、迁移问题、未解决的问题。记录其他选项被放弃的原因；这将成为“已考虑的备选方案”。
6. 协调资源
就交付形态达成一致，而不是单个工单：阶段或里程碑以及每个阶段展示什么、首先验证风险最高的部分、功能标志和迁移策略、测试策略、上线和回滚、以及需要监控什么。详细的工单分解由 /task-breakdown 后续从 RFC 中进行。结束时提供生成 RFC 的选项。
RFC 模式
- 查找讨论：使用到目前为止的对话以及存在的笔记文件。如果根本没有讨论，则说明并提供开始一个讨论的选项：要求提供问题陈述并开始第 1 步。
- 如果有缺失的步骤，列出它们并询问是现在补充还是用这些部分标记 TBD 起草 RFC。不要发明用户未做出的决定。
- 选择输出位置。RFC、笔记和任务文件是开发者的本地工作文档：默认不被追踪，不与代码一起提交。寻找一个现有的本地、被 git 忽略的文件夹（检查
.gitignore和.git/info/exclude）并遵循其命名。如果没有，则建议.rfcs/YYYY-MM-DD-<slug>.md并将.rfcs/添加到.git/info/exclude，这将本地忽略它而无需改动仓库的.gitignore。仅当用户说团队提交 RFC 时才使用被追踪的文件夹如docs/rfcs/。 - 使用 templates/rfc.md 编写 RFC，从讨论中填充每个部分，并将代码库声明与文件路径联系起来。
- 告知用户路径，并列出任何 TBD 部分和未解决的问题。
- 提供下一步：
/task-breakdown <rfc-path>将 RFC 转化为团队可以领取的 1-故事点工单。