wgm

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.

Step 6: Ship / Handoff

Summarize what shipped and how to validate it, run a mandatory four-persona docs-audit pass

(junior/senior/principal/PM perspectives, consolidated into one paper-trail report), and harvest any

durable, cross-project lesson back into the shared skill's own ledger.

Examples

Example 1: Full lifecycle from a rough request

User: "Build a CLI todo app with add/list/complete commands, from scratch."

wgm states its Track (Standard), grills for the ~3-5 unknowns that actually matter, writes specs +

IMPLEMENTATION_PLAN.md, scores Preflight readiness, then loops one task at a time — each task's

own test/lint/build command must exit 0 before it's marked done — and finally ships with a

docs-audit pass.

Example 2: Scoped planning only

User: "/wgm plan: add OAuth login to this existing Express API"

wgm writes the specs and plan, then hard-stops at the Plan-exit gate without starting the build loop

— useful when a human wants to review the plan before any code is touched.

Best Practices

• Do let the plan be the shared state — a fresh agent should be able to resume a build from

IMPLEMENTATION_PLAN.md alone.

• Do keep holdout scenarios genuinely hidden from the generating agent; that's what prevents a

judged score from being gamed.

• Do map every acceptance criterion to a runnable, deterministic check before calling anything done.
• Don't skip the alignment interview on ambiguous, multi-week, or security/UX-critical work just to

move faster — misalignment discovered after building is far more expensive.

• Don't treat a high satisfaction score as sufficient on its own — a failing deterministic check

always overrides it.

Limitations

• wgm is a protocol, not a runtime: it has no daemon, scheduler, or bundled dashboard — it expects

an existing agentskills.io-compatible host to load and execute it.

• This skill does not replace environment-specific validation, testing, or expert review.
• Full holdout-scenario judging and the docs-audit swarm add ceremony that a genuinely trivial task

does not need — wgm's own Triage track exists specifically to right-size this, and the skill

explicitly says not to use it for one-file edits or pure debugging.

Common Pitfalls

• Problem: Treating wgm's "build" mode the same as a full-lifecycle request.

Solution: /wgm build resumes an existing IMPLEMENTATION_PLAN.md; a bare request like

"build the auth module" (more text after "build") is a full-lifecycle request, not build mode.

• Problem: Letting the agent peek at holdout scenarios while implementing.

Solution: Scenarios are read only during Validate/Review, never during Implement — that's the

entire point of a holdout set.

Related Skills

• @grill-me - the narrower alignment-interview primitive wgm's Grill phase is adapted from.
• @skill-creator - useful for authoring/evaluating the skill itself; wgm ships its own eval

fixture (evals/evals.json) using the same eval-driven-iteration discipline.

Additional Resources

• Repository
• Full protocol (SKILL.md)
• Reference library