| 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
Overview
wgm ("well, gosh... make") is a portable build methodology, not a domain skill — a single
SKILL.md protocol that any agentskills.io-compatible host loads to turn a rough request into
working software. It marries three ideas: a relentless alignment interview before any code is
written, a Ralph-style loop (one task per iteration, a persistent plan as shared state, steered by
deterministic backpressure), and holdout-scenario LLM judging (scenarios the build never sees, so a
high satisfaction score can't be gamed). It also runs its own internal docs-audit and
self-improvement loop, cross-pollinating durable lessons from sibling agent-coding projects back
into its own protocol.
When to Use This Skill
- Use when building or implementing a feature, app, or prototype from rough or ambiguous intent.
- Use when a task benefits from a governed plan plus iterative, test-validated execution rather
than one-shot generation.
- Use when you want a build to converge against acceptance criteria an LLM judge scores blind
(0-100), instead of trusting a single self-reported "looks good."
- Not for trivial one-file edits, pure debugging, research-only questions, or tasks that already
have complete, unambiguous step-by-step instructions — wgm explicitly stays out of the way there.
How It Works
Step 1: Triage
Classify the work onto a scale-adaptive track (Quick / Standard / Full) so ceremony matches risk —
a one-file fix skips holdout scenarios and the docs-audit swarm; a greenfield app gets the full rig.
The deterministic backpressure gate itself is never skipped, only the ceremony around it.
Step 2: Grill (align)
Interview the user one question at a time, always with a recommended answer, until the goal,
success criteria, and constraints are known — capping interrogation after ~5 questions to avoid
theater. Explore the codebase to self-answer before asking anything a human doesn't need to weigh
in on.
Step 3: Plan
Produce a project constitution, one spec per coherent slice (each with a magic moment and a demo
path), holdout acceptance scenarios the build must never read, and IMPLEMENTATION_PLAN.md — the
persistent shared state across every later iteration. Cross-check every artifact against every other
one before moving on.
Step 4: Preflight
Score the plan's readiness 0-100 across goal clarity, observable success criteria, scenario
coverage, and backpressure mapping. Below the threshold, return to Grill/Plan and fix the weakest
dimension — do not start building on a shaky plan.
Step 5: Loop (build)
Run Analyze -> Implement -> Validate -> Review -> Record, one task per iteration: pick the single
most important pending task, make the smallest change that completes it, run its deterministic
validation command (green or it isn't done), judge holdout-scenario satisfaction, review the diff
for scope creep, then record status and any durable lesson before advancing exactly one task.
