reforge

Reforge

你正在运行 reforge 入门流程。你的任务是从原型或 PoC 中提取意图和经验教训，然后舍弃其实现。输出文件 reforge-seed.md 将交给一个全新的 architect 会话，用于构建全新的生产级代码库。你不是在改进原型，而是在从中挖掘知识，让新系统从更高的起点开始。

运行辅助脚本

此技能将辅助脚本打包在自己的 scripts/ 目录中（与此 SKILL.md 一起安装）。将 SKILL_DIR 设置为此技能的绝对路径——在本文件末尾显示为 此技能的基础目录——然后从你的项目根目录运行脚本（这些脚本会操作项目的 .changes/ 和 CONTEXT.md 文件）：

SKILL_DIR="<absolute path to this skill's directory>"

以下所有 node "$SKILL_DIR/scripts/..." 命令都依赖于此设置。切勿引用 packages/build/——该路径只存在于工具包的开发代码库中，在已安装的技能中并不存在。

你的立场

有选择性地审视。你要寻找：

• 原型验证了什么。 哪些能力有效，必须保留到生产版本中。
• 原型揭示了什么。 作者未曾预料到的复杂性、边缘情况和故障模式。
• 哪些内容绝不能沿用。 实现上的捷径、错误的抽象和偶然形成的模式。

这需要坦诚。PoC 作者往往会执着于原型中的模式。你的工作是透过实现，看到底层意图。

前期了解

在探索代码、使用子 Agent 或阅读参考资料之前，先了解目标和可观察到的结果、影响范围、约束和反目标，以及需求是已明确、部分明确还是尚未明确。根据答案限定 PoC 的探索范围。

阶段 1：理解 PoC

运行探索子 Agent，了解原型——不是为了记录它，而是为了提取意图。

探索 Agent 1——能力：

“探索此代码库。它能做什么？从用户/系统行为和结果的角度描述其能力，而不是从实现的角度。它解决了什么问题？它明确不会做什么？”

探索 Agent 2——领域复杂性：

“探索此代码库。最难解决的问题是什么？哪些地方的代码最复杂或注释最多？实现处理了哪些边缘情况？哪些边缘情况似乎被搁置了？在生产负载下或面对真实用户时，什么会出问题？”

探索 Agent 3——实现质量：

“探索此代码库。采用了哪些实现捷径？哪些模式明显只有 PoC 的质量（硬编码值、跳过验证、缺少错误处理、假设只有单个用户）？哪些抽象看起来不合适或是偶然形成的？你会先重写什么？”

在编写 seed 之前，先展示发现并与用户讨论。

阶段 2：访谈 — 意图与经验教训

这是一次简短、聚焦的访谈。目标：结合用户的亲身经验，确认并补充探索阶段的发现。

问题（一次问一个，并对答案提出质疑）：

1. PoC 中哪些功能必须在生产系统中保留？（明确列举。）
2. 哪些功能经过探索，但不应纳入生产系统？（反目标。）
3. 构建 PoC 时，你学到的最令人意外的事情是什么？
4. 如果今天重新开始，你会彻底改变什么做法？
5. PoC 中是否有正确命名的领域术语或概念？（这些会沿用到术语表中。）
6. 是否有命名或建模不正确的领域术语或概念？（这些应在新系统中修正。）
7. 生产系统需要满足哪些 PoC 从未涉及的验收标准？
8. 生产系统的目标语言／技术栈是什么？（用于确定惯用法的背景。）

对含糊的回答提出质疑。“我会重构架构”不算答案。“事件循环模型不对，因为 X；我会改用 Y”才算答案。

确定目标语言后，使用 idioms 技能加载匹配的工具包，并针对实现反模式和建议的生产方案提出质疑。如果没有安装匹配的工具包，请说明这一点，并采用目标生态中成熟的惯例和工具，而不是假设工具包提供了指导。

阶段 3：编写 reforge-seed.md

填写 references/templates/reforge-seed.md.tmpl。内容要具体、明确。含糊的种子会产出含糊的架构。

请认真填写以下字段：

• 功能意图 — 描述行为和结果，而非实现方式
• 必须保留的功能 — 具体明确，避免泛泛而谈
• 反目标 — 明确说明并给出理由
• 经验教训 — 最有价值的产出。要具体到可采取行动。
• 需要避免的实现反模式 — 每项都应说明“为什么不好，以及应该怎么做”
• 已知领域复杂性 — 在生产环境中仍会遇到的难点
• 粗略验收标准 — 架构师会话的高层行为要求
• 架构师会话要解决的问题 — PoC 提出但尚未回答的开放问题

写入到：自行选择的位置（reforge seed 并非当前变更的产物，而是一个起点）。

建议路径：新项目未来所在位置的根目录下的 reforge-seed.md，或用户之后可以移动的临时文件。

阶段 4：交接给架构师

向用户展示 seed，并逐项过一遍。确认：

• 功能列表完整。
• 反目标如实。
• 经验教训足够具体，可作为架构师会话中可执行的挑战。
• 架构师会话需要解决的问题确实存在信息缺口。

然后：

“reforge seed 已准备就绪。请为生产系统创建一个新仓库，并在其中运行 architect，让它参考此 seed。架构师会话将以粗略验收标准和问题作为起始挑战。”

如果已知目标语言，请说明：

“创建架构师变更清单时，设置 manifest.language = <lang> 以加载惯用法工具包。”

reforge 不会做什么

• 它不会创建 CONTEXT.md（新仓库尚无代码；architect 会在第一个实现周期后创建，或由 map 在第一个可运行版本后创建）。
• 它不会自行运行 architect，而是准备 seed。用户应先创建新仓库。
• 它不会建议沿用 PoC 中的任何实现代码。如果用户想移植代码，由用户自行决定；请将此事作为 seed 中的一个具体问题提出。

参考文件

• references/templates/reforge-seed.md.tmpl
• references/templates/CONTEXT.md.tmpl — 供参考，了解 architect 将生成什么
• references/challenge-protocol.md
• idioms 技能 — 如果目标语言已知