用途：把只在聊天里争论的设计变成可审阅、可交接的 RFC。RFC 只主张一个方案，不做决定；被接受后的持久决策归入 ADR，是否保留 RFC 由项目治理决定。
主要能力与结构：RFC 包含 Problem（迫使提案的技术压力，引用 PRD、发现或审计来源）、Proposal（唯一主张的方案，散文描述而非需求）、Alternatives（表格，列出替代方案及为何更弱，至少一行真实内容）、Migration plan（从现状到提案的有序步骤）、Open questions（每条标注 blocking 或 non-blocking）、Decision requested（请求的具体决策及接受后去向：ADR、规格或两者）。
使用方式：文件放在其将先于的规格旁边，扁平文件，frontmatter 中 type: rfc，status 为 proposed | accepted | rejected | superseded。文件置于 ~/.agents/artifacts/<workspace>/，~ 解析为绝对家目录路径，<workspace> 取自仓库或工作目录的 basename；保持在仓库之外并携带其绝对路径。若工作区名或目标路径与无关工作冲突，停下让人工结构化选择，绝不覆盖；根目录不可写时提供授权重试、换用其他 agent 中立用户目录或取消，绝不回退到厂商存储、仓库或临时目录。接受后据其写 ADR 和/或规格并注明 RFC 为来源；若保留 RFC，状态改为 accepted。
限制与常见错误：Proposal 中写需求（如“API 必须返回 429”）、Alternatives 表为空、用模糊措辞掩盖真实开放问题、在 blocking 问题未解决时请求决策、为已做出的决定写 RFC（那应写 ADR）。完成前自查：每句都是决策前措辞，无“we will”或“the system must”；Problem 引用上游来源；只主张一个方案；Alternatives 非空；迁移计划有序；开放问题均标注；请求的决策指明目标。资料未提供具体命令或安装方式。