name: wgmdescription: “Turns a rough request into working software via a governed build loop: align first, plan, then iterate one task at a time with deterministic backpressure and holdout-scenario judging.”category: metarisk: safesource: communitysource_repo: agent-frontier/wgmsource_type: officialdate_added: “2026-07-05”author: agent-frontiertags: [build-loop, spec-driven, ralph-loop, self-improving, agentic-development, methodology]tools: [claude, cursor, gemini, copilot, codex]license: “MIT”license_source: “https://github.com/agent-frontier/wgm/blob/main/LICENSE”wgm概述wgm“well, gosh… make”是一种可移植的构建方法论而不是领域技能——它是一个单一的SKILL.md协议任何 agentskills.io 兼容的主机都可以加载它将粗略的请求转化为可工作的软件。它融合了三个理念在编写任何代码之前进行不遗余力的对齐访谈Ralph 式循环每次迭代一个任务以持久计划作为共享状态由确定性背压驱动以及保留场景holdout-scenarioLLM 评判构建过程从未见过的场景因此高分无法被操纵。它还运行自己的内部文档审计和自我改进循环将来自同类代理编码项目的持久经验交叉反哺到自己的协议中。何时使用本技能从粗略或模糊的意图构建或实现功能、应用或原型时使用。任务受益于受控计划加迭代式、测试验证的执行而非一次性生成时使用。希望构建过程收敛到由 LLM 评判者盲评0-100的验收标准而不是信任单一的自述看起来不错时使用。不适用于琐碎的单文件编辑、纯调试、仅研究性质的问题或已有完整、无歧义的分步指令的任务——wgm 明确在这些情况下不插手。工作原理第 1 步分诊Triage将工作分类到可缩放调整的轨道快速 / 标准 / 完整使流程仪式与风险匹配——单文件修复跳过保留场景和文档审计集群全新应用则使用完整流程。确定性背压门控本身从不跳过只跳过围绕它的仪式。第 2 步盘问Grill对齐一次一个问题地访谈用户始终附带推荐答案直到目标、成功标准和约束都明确为止——在约 5 个问题后停止追问避免形式主义。在提出任何需要人类权衡的问题之前先探索代码库以自行回答。第 3 步计划Plan产出一份项目章程每个连贯切片一份规格每份都包含一个神奇时刻和演示路径、构建过程绝不允许读取的保留验收场景以及IMPLEMENTATION_PLAN.md——这是后续每次迭代中的持久共享状态。在继续之前将每份产物与其他产物交叉核对。第 4 步预检Preflight从目标清晰度、可观察的成功标准、场景覆盖率和背压映射四个维度对计划就绪度评分0-100。低于阈值则返回盘问/计划阶段修复最薄弱的维度——不要在摇摇欲坠的计划上开始构建。第 5 步循环Loop构建运行分析 - 实现 - 验证 - 审查 - 记录每次迭代一个任务挑选唯一最重要的待办任务做完成它所需的最小改动运行其确定性验证命令通过才算完成评判保留场景满意度审查 diff 是否存在范围蔓延然后记录状态和任何持久经验再推进恰好一个任务。第 6 步交付 / 交接Ship / Handoff总结交付了什么以及如何验证运行强制性的四角色文档审计初级/高级/资深/项目经理视角合并为一份留有痕迹的报告并将任何持久的跨项目经验回收到共享技能自己的记录中。示例示例 1从粗略请求开始的完整生命周期User: Build a CLI todo app with add/list/complete commands, from scratch.wgm 声明其轨道标准盘问真正重要的约 3-5 个未知项编写规格 IMPLEMENTATION_PLAN.md对预检就绪度评分然后一次一个任务地循环——每个任务自己的测试/lint/构建命令必须退出码为 0 才标记完成——最后带着文档审计通过交付。示例 2仅限范围的规划User: /wgm plan: add OAuth login to this existing Express APIwgm 编写规格和计划然后在计划退出门控处硬性停止不启动构建循环——当人类希望在触碰任何代码之前审查计划时这很有用。最佳实践让计划成为共享状态——一个全新的代理应该能仅凭IMPLEMENTATION_PLAN.md恢复构建。让保留场景真正对生成代理隐藏这正是防止评判分数被操纵的关键。在宣布任何事完成之前将每条验收标准映射到可运行、确定性的检查。不要为了更快推进而跳过模糊、跨多周或安全/UX 关键工作的对齐访谈——构建之后才发现不一致的代价要高得多。不要将高分满意度视为充分的完成条件——失败的确定性检查始终优先于它。局限性wgm 是协议不是运行时它没有守护进程、调度器或捆绑的仪表板——它期望现有的 agentskills.io 兼容主机来加载和执行它。本技能不能替代环境特定的验证、测试或专家审查。完整的保留场景评判和文档审计集群会增加仪式成本而真正琐碎的任务不需要这些——wgm 自己的分诊轨道正是为了正确调整规模而存在而且该技能明确表示不要将其用于单文件编辑或纯调试。常见陷阱问题将 wgm 的build模式与完整生命周期请求混为一谈。解决方案/wgm build恢复的是已有的IMPLEMENTATION_PLAN.md一个裸请求如构建认证模块build后面还有更多文本是完整生命周期请求而不是build模式。问题让代理在实现期间偷看保留场景。解决方案场景只在验证/审查阶段读取绝不在实现阶段读取——这正是保留集的意义所在。相关技能grill-me- 更狭窄的对齐访谈原语wgm 的盘问阶段改编自它。skill-creator- 对编写/评估技能本身有用wgm 自带评估夹具evals/evals.json使用相同的评估驱动迭代纪律。其他资源仓库完整协议SKILL.md参考库
name: wgmdescription: “Turns a rough request into working software via a governed build loop: align first, plan, then iterate one task at a time with deterministic backpressure and holdout-scenario judging.”category: metarisk: safesource: communitysource_repo: agent-frontier/wgmsource_type: officialdate_added: “2026-07-05”author: agent-frontiertags: [build-loop, spec-driven, ralph-loop, self-improving, agentic-development, methodology]tools: [claude, cursor, gemini, copilot, codex]license: “MIT”license_source: “https://github.com/agent-frontier/wgm/blob/main/LICENSE”wgm概述wgm“well, gosh… make”是一种可移植的构建方法论而不是领域技能——它是一个单一的SKILL.md协议任何 agentskills.io 兼容的主机都可以加载它将粗略的请求转化为可工作的软件。它融合了三个理念在编写任何代码之前进行不遗余力的对齐访谈Ralph 式循环每次迭代一个任务以持久计划作为共享状态由确定性背压驱动以及保留场景holdout-scenarioLLM 评判构建过程从未见过的场景因此高分无法被操纵。它还运行自己的内部文档审计和自我改进循环将来自同类代理编码项目的持久经验交叉反哺到自己的协议中。何时使用本技能从粗略或模糊的意图构建或实现功能、应用或原型时使用。任务受益于受控计划加迭代式、测试验证的执行而非一次性生成时使用。希望构建过程收敛到由 LLM 评判者盲评0-100的验收标准而不是信任单一的自述看起来不错时使用。不适用于琐碎的单文件编辑、纯调试、仅研究性质的问题或已有完整、无歧义的分步指令的任务——wgm 明确在这些情况下不插手。工作原理第 1 步分诊Triage将工作分类到可缩放调整的轨道快速 / 标准 / 完整使流程仪式与风险匹配——单文件修复跳过保留场景和文档审计集群全新应用则使用完整流程。确定性背压门控本身从不跳过只跳过围绕它的仪式。第 2 步盘问Grill对齐一次一个问题地访谈用户始终附带推荐答案直到目标、成功标准和约束都明确为止——在约 5 个问题后停止追问避免形式主义。在提出任何需要人类权衡的问题之前先探索代码库以自行回答。第 3 步计划Plan产出一份项目章程每个连贯切片一份规格每份都包含一个神奇时刻和演示路径、构建过程绝不允许读取的保留验收场景以及IMPLEMENTATION_PLAN.md——这是后续每次迭代中的持久共享状态。在继续之前将每份产物与其他产物交叉核对。第 4 步预检Preflight从目标清晰度、可观察的成功标准、场景覆盖率和背压映射四个维度对计划就绪度评分0-100。低于阈值则返回盘问/计划阶段修复最薄弱的维度——不要在摇摇欲坠的计划上开始构建。第 5 步循环Loop构建运行分析 - 实现 - 验证 - 审查 - 记录每次迭代一个任务挑选唯一最重要的待办任务做完成它所需的最小改动运行其确定性验证命令通过才算完成评判保留场景满意度审查 diff 是否存在范围蔓延然后记录状态和任何持久经验再推进恰好一个任务。第 6 步交付 / 交接Ship / Handoff总结交付了什么以及如何验证运行强制性的四角色文档审计初级/高级/资深/项目经理视角合并为一份留有痕迹的报告并将任何持久的跨项目经验回收到共享技能自己的记录中。示例示例 1从粗略请求开始的完整生命周期User: Build a CLI todo app with add/list/complete commands, from scratch.wgm 声明其轨道标准盘问真正重要的约 3-5 个未知项编写规格 IMPLEMENTATION_PLAN.md对预检就绪度评分然后一次一个任务地循环——每个任务自己的测试/lint/构建命令必须退出码为 0 才标记完成——最后带着文档审计通过交付。示例 2仅限范围的规划User: /wgm plan: add OAuth login to this existing Express APIwgm 编写规格和计划然后在计划退出门控处硬性停止不启动构建循环——当人类希望在触碰任何代码之前审查计划时这很有用。最佳实践让计划成为共享状态——一个全新的代理应该能仅凭IMPLEMENTATION_PLAN.md恢复构建。让保留场景真正对生成代理隐藏这正是防止评判分数被操纵的关键。在宣布任何事完成之前将每条验收标准映射到可运行、确定性的检查。不要为了更快推进而跳过模糊、跨多周或安全/UX 关键工作的对齐访谈——构建之后才发现不一致的代价要高得多。不要将高分满意度视为充分的完成条件——失败的确定性检查始终优先于它。局限性wgm 是协议不是运行时它没有守护进程、调度器或捆绑的仪表板——它期望现有的 agentskills.io 兼容主机来加载和执行它。本技能不能替代环境特定的验证、测试或专家审查。完整的保留场景评判和文档审计集群会增加仪式成本而真正琐碎的任务不需要这些——wgm 自己的分诊轨道正是为了正确调整规模而存在而且该技能明确表示不要将其用于单文件编辑或纯调试。常见陷阱问题将 wgm 的build模式与完整生命周期请求混为一谈。解决方案/wgm build恢复的是已有的IMPLEMENTATION_PLAN.md一个裸请求如构建认证模块build后面还有更多文本是完整生命周期请求而不是build模式。问题让代理在实现期间偷看保留场景。解决方案场景只在验证/审查阶段读取绝不在实现阶段读取——这正是保留集的意义所在。相关技能grill-me- 更狭窄的对齐访谈原语wgm 的盘问阶段改编自它。skill-creator- 对编写/评估技能本身有用wgm 自带评估夹具evals/evals.json使用相同的评估驱动迭代纪律。其他资源仓库完整协议SKILL.md参考库
