wgm

name: wgm
description: “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: meta
risk: safe
source: community
source_repo: agent-frontier/wgm
source_type: official
date_added: “2026-07-05”
author: agent-frontier
tags: [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（“well, gosh… make”）是一种可移植的构建方法论，而不是领域技能——它是一个单一的SKILL.md协议，任何 agentskills.io 兼容的主机都可以加载它，将粗略的请求转化为可工作的软件。它融合了三个理念：在编写任何代码之前进行不遗余力的对齐访谈；Ralph 式循环（每次迭代一个任务，以持久计划作为共享状态，由确定性背压驱动）；以及保留场景（holdout-scenario）LLM 评判（构建过程从未见过的场景，因此高分无法被操纵）。它还运行自己的内部文档审计和自我改进循环，将来自同类代理编码项目的持久经验交叉反哺到自己的协议中。

何时使用本技能

从粗略或模糊的意图构建或实现功能、应用或原型时使用。
任务受益于受控计划加迭代式、测试验证的执行，而非一次性生成时使用。
希望构建过程收敛到由 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 API"

wgm 编写规格和计划，然后在计划退出门控处硬性停止，不启动构建循环——当人类希望在触碰任何代码之前审查计划时，这很有用。

最佳实践

让计划成为共享状态——一个全新的代理应该能仅凭IMPLEMENTATION_PLAN.md恢复构建。
让保留场景真正对生成代理隐藏；这正是防止评判分数被操纵的关键。
在宣布任何事完成之前，将每条验收标准映射到可运行、确定性的检查。
不要为了更快推进而跳过模糊、跨多周或安全/UX 关键工作的对齐访谈——构建之后才发现不一致的代价要高得多。
不要将高分满意度视为充分的完成条件——失败的确定性检查始终优先于它。

局限性

wgm 是协议，不是运行时：它没有守护进程、调度器或捆绑的仪表板——它期望现有的 agentskills.io 兼容主机来加载和执行它。
本技能不能替代环境特定的验证、测试或专家审查。
完整的保留场景评判和文档审计集群会增加仪式成本，而真正琐碎的任务不需要这些——wgm 自己的分诊轨道正是为了正确调整规模而存在，而且该技能明确表示不要将其用于单文件编辑或纯调试。

常见陷阱

问题：将 wgm 的"build"模式与完整生命周期请求混为一谈。
解决方案：/wgm build恢复的是已有的IMPLEMENTATION_PLAN.md；一个裸请求如"构建认证模块"（"build"后面还有更多文本）是完整生命周期请求，而不是build模式。
问题：让代理在实现期间偷看保留场景。
解决方案：场景只在验证/审查阶段读取，绝不在实现阶段读取——这正是保留集的意义所在。