octocode-rfc-generator

Octocode RFC 生成器

生成有证据支撑的决策，让实现者和评审者都能据此执行。 流程：UNDERSTAND → RESEARCH → PREREQUISITES → COMPARE → WRITE → CLOSE QUESTIONS → KPI → VALIDATE → DELIVER。 对于现有 RFC，运行 REASSESS（参见 references/workflow.md § Reassess existing RFCs），而不是 WRITE；依据当前代码审查，不依据先前勾选的项目。

讨论规则

• 对琐碎的编辑，跳过 RFC 模式。如果不确定性会改变产物形式、负责人、范围或决策标准，则提出一个有针对性的问题。
• 至少比较两个备选方案，包括不采取行动，除非用户明确要求只提供一个实现方案。
• 建议必须有可验证的事实支撑；引用确切的定位信息，以及实际运行过的命令／检查。
• RFC.md 负责记录目标、范围和决策。其他文件应链接到其中的定位信息，而不是重复陈述。
• 用证据或明确延期的方式解决每个未决问题；任何建议都不得基于不确定的说法。
• 按依赖关系而非估算值安排实现顺序；将需求与验收和验证关联起来。
• 审查、评分或清理 .octocode/rfc/（删除／已实现／已修复等判定）时，必须始终在 RFC 本身中写入注明日期的 ## Audit Reasoning 区块，并以对当前代码的最新审查为依据。
• 绝不凭记忆或其他 RFC 中的说法断言 RFC 状态。
• 在以下情况下停止：变更只是对单个文件的琐碎编辑（转交给 octocode-research）；头脑风暴交接标记为 Prototype First、Narrow、Park 或尚未就绪；不确定性会改变产物形式、负责人、范围或权衡优先级；两次研究尝试均告失败（说明已知信息并寻求指示）；范围需要拆分为多个 RFC 或阶段；必须假定某个未解决的阻碍已解决；或者 .octocode/rfc/ 下的保存、删除或归档操作仍待明确批准。

产物路径

• 小型、可逆的单包工作：仅生成 RFC.md，其中包含计划、验收标准和内联引用。
• 否则，在获得保存批准后，创建 <workspace>/.octocode/rfc/{name}/：RFC.md（决策）、PREREQUISITES.md（就绪情况，仅限现有代码）、IMPLEMENTATION.md（构建）、KPI.md（验证）和 RESOURCES.md（来源附录）。

智能路径——仅加载当前步骤所需内容

• 为理解需求并在起草前选择模式，加载 references/workflow.md——关卡、主张台账、产物集合、可追溯性、验证和交付顺序。
• 研究证据时，先加载 references/octocode.md，再加载 references/research-playbook.md——委派具体研究任务，并确保主张可审计。
• 现有代码需要就绪工作时，在制定计划前加载 references/rfc-prerequisites.md——明确基线、阻碍、负责人和准备工作。
• 比较选项并撰写决策时，加载 references/rfc-template.md——组织备选方案、目标／非目标、可逆性和预演分析。
• 制定执行计划时，加载 references/rfc-implementation.md——解决未决问题，安排依赖关系，并定义发布／回滚方案。
• 定义验收标准和 KPI 目标时，加载 references/rfc-kpi.md——在可追溯性矩阵中关联用户故事、指标、决策规则和验证方式。
• 保留来源时，加载 references/rfc-resources.md——记录来源信息，但不要将关键引用从 RFC 中移出。
• 重新评估、评分或清理现有 RFC 时，加载 references/rfc-audit.md——在判定保留／修复／删除之前，必须写入注明日期且包含当前代码证据的 ## Audit Reasoning 区块。
• 改进此技能时，优先使用 octocode-graph-eval；否则加载 references/improve-loop.md——确保验收／回滚具备可衡量性。

相关流程与验证

• 如果是否值得构建尚未确定，请在 RFC 前使用 octocode-brainstorming；使用 octocode-research 解答事实问题；使用 octocode-graph-eval 确保 KPI 严谨性。
• 修改此技能文件夹时，请使用 octocode-skills。
• 交付前，逐节验证文档约定，并报告实际结果。