build-loop

What it does

Drives a build that compiles but isn’t finished toward near-finish-line craft by looping through a disciplined cycle: build → see → exercise → check → critique → rebuild. It uses the agent’s existing tools (bash build/test, headless screenshot + vision, Playwright, axe/Lighthouse) to observe, exercise, and validate the build until acceptance criteria pass or a stop-condition fires. It is invoked when the user asks to tighten or iterate the build, self-verify the UI, or drive a near-finish-line result, and can run proactively after scaffolds or features land before handing to a human. It is composition-first and does not decide WHAT to build or whether the design is sound; it focuses on objective craft and design-critique only as applicable. It emphasizes an honest ledger of checks and a per-iteration report, with a configurable stop condition and a finite budget to prevent infinite loops.

How it works

• It starts from a build that compiles but isn’t finished and repeats the loop: build → see → exercise → check → critique → rebuild. It records observations from each step and feeds them back into the next rebuild.
• It orchestrates existing tools: bash (build/test), headless screenshot + vision to see, Playwright/headless to exercise flows, and axe/Lighthouse to check accessibility and performance. It conveys results in prose to guide improvements rather than executing a new program.
• It requires locking acceptance criteria and a design bar before iterating. Per iteration, it performs:
  1. Build & test via bash and records exit codes and pass counts.
  2. See — render running UI or use a renderer/Playwright to capture key states across ≥2 viewports and critique against the brief and design craft, reporting defects with severity.
  3. Exercise — drive core flows headless (click, fill, navigate) and verify input/output coupling.
  4. Check — run axe for accessibility and Lighthouse for performance budgets; scan for broken assets/links.
  5. Critique — list defects with severity and tie them to acceptance criteria.
  6. Rebuild — fix top defects from both machine and design tracks and loop again until stop conditions.
• It maintains a per-iteration ledger of objective signals and design-taste judgments; reports iteration count, open defects, and what remains to be done.
• Stop conditions include PASS (all criteria met and defects closed), PLATEAU (2 consecutive iterations with no progress), BUDGET (rebuild cap), or BLOCKED (needs human input). It never fakes signals, and never continues past the defined stops without explicit conditions.

When to use it

• Strong triggers: "Tighten this build", "drive it to near-finish-line", "make it actually work, not just compile", "Iterate until it passes", "Self-verify the UI", "loop until the core flows pass".
• Softer triggers: after scaffolds or features land, or before handing a draft to a human to ensure machine-checkable defects are cleared.
• Do not use for: deciding what to build, judging design soundness, or validating user demand.

What it can touch

• The skill touches: bash (build/test), headless screenshot + vision, Playwright/headless, axe, Lighthouse.
• It relies on these tools to run builds, render UI, exercise flows, and perform accessibility and performance checks; it does not, by itself, implement changes outside these tools.

Caveats

• It is bounded by a ceiling of craft (approximately 80%), with design taste partially assessed by different-model critique when applicable; final design sign-off still requires human review.
• The loop cannot determine market validation or external truth beyond its checks; those aspects are out of scope.
• It requires that acceptance criteria are defined upfront and that a design bar is provided when design is load-bearing; otherwise the loop emphasizes objective signals and defect tracking.