create-rfc

创建 RFC

每次调用生成一个 RFC。RFC 用于提出尚未做出的决策，并推动利益相关方达成共识；如果决策已经做出，请使用 /create-adr 记录。按顺序遵循五步流程：第 2 步会验证必填字段，所有必填字段齐备后即可开始起草。

硬性规则

• 绝不编造事实。 如果缺少必填字段，就提出询问。绝不在背景、假设或选项中填入听起来合理的套话。
• 绝不把既定结论伪装成待议事项。 如果只有一个真实可选项，这份文档就是 ADR，而不是 RFC——请改用 /create-adr。
• 先写决策标准，再列选项。 在列出选项后才写标准，会显得像是在为偏好的选择找理由。
• 对任何重大变更，都要明确列出“维持现状”这一选项——哪些变更属于重大变更，由通用规则 2 定义。
• 绝不跳过权衡分析。 每个选项都必须如实列出优点和缺点。
• 使用用户的语言撰写——即用户在本次会话中使用的语言，文档中的每个部分都要如此。

执行流程

按顺序执行流程。采取行动前，完整阅读对应的参考文件——它是该步骤的操作指南。

步骤	阅读	目的
1 — 收集背景	references/process.md	询问主题、影响、紧迫性和已有想法的选项
2 — 验证必填字段	references/process.md	确保标题、背景、RACI、标准、选项和建议均已提供
3 — 按 RFC 类型调整	references/types.md	技术 / 流程 / 产品 / 供应商 / 政策——各自需要重点关注的方面
4 — 生成	templates/rfc.md + references/numbering.md	填写模板、分配编号、运行质量检查清单
5 — 确定存放位置并规划后续步骤	references/process.md	确认文件位置，输出摘要和后续事项

定稿前运行质量检查清单（references/quality.md）——检查选项是否客观、标准是否有权重、背景是否量化、假设是否明确。

模板

纯 Markdown 脚手架。仅在撰写时加载：

• templates/rfc.md — 包含必填和推荐部分。删除任何内容为空的推荐部分；即使值为 *to be confirmed*，也要保留每个必填部分。

通用规则

1. 诚实。 根据标准如实比较选项；优缺点必须真实；明确列出假设及其可信度和失效触发条件。
2. “维持现状”始终是重大变更的一个选项——它能促使人们如实评估变更是否值得付出成本。重大变更是指第 1 步记录的影响级别为 HIGH 或 MEDIUM（涉及多个团队 / 系统 / 用户，或一个完整团队或系统）。影响较低的变更——范围有限且易于撤销——可以省略维持现状这一选项，但要用一行说明原因，不能让读者自行猜测。这是本技能中对重大变更的唯一界定；其他所有提及均以此为准。
3. 起草期间，“结果”是占位内容——决策做出后再填写；如果该决策值得留存，则链接到由此产生的 ADR。
4. RFC 用于决策，而非实施。 决策一旦做出，就交由 /create-adr 记录，并交由 /forge 构建。
5. 所有内容都要注明日期，并在开始时记录影响级别。
6. 写入前先确认。 在第 5 步建议文件路径；只有用户确认存放位置后才能写入。

相关技能

在流程的任何阶段都可以使用以下技能：

• /create-adr — 决策已经做出。使用 ADR 记录决策的内容、原因和后果，作为不可更改的历史记录。RFC → 决策 → ADR 是重大决策的自然流程。
• /forge — 由规范驱动的实施。RFC 决策完成后，使用 /forge specify | design | plan | execute 将选定方案拆解为可交付的工作。

署名

基于 create-rfc， 由 Tech Leads Club 提供，并采用 CC-BY-4.0 许可。已对原内容进行修改。