agentsclimarketplace
Sign in

Loop

Skill TomWebwalker/skills/skills/loop

Run a build-then-verify loop until the repo's quality gates pass. Dispatches a builder to implement the task and a checker to run the gates, feeding failures back until green or the cycle budget runs out. Reads per-repo config from docs/agents/, so it works in any language.From its SKILL.md

Install
npx -y skills add TomWebwalker/skills --skill loop

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.1 KB, as published. Nobody here has run it

Run this task as a loop: $ARGUMENTS

Load config first. Read docs/agents/vcs.md, docs/agents/stack.md, docs/agents/quality-gates.md, and docs/agents/topology.md (if present). If the first three are missing, suggest /setup-project-skills and fall back to loop.max_cycles: 5. Every command, branch name, and stop condition below comes from config — nothing about this loop is repo-specific. Missing topology.md means treat the repo as self-contained (same as role: standalone).

Roles. The loop dispatches two subagents, named in quality-gates.md#loop:

  • builder (loop.builder_agent, default builder) — writes and fixes code.
  • checker (loop.checker_agent, default checker) — runs /verify-feature and reports. Never edits.

If a named subagent isn't installed, don't fail: run that role inline as a phase of this conversation, holding to the same contract (the build phase edits code and reports one line; the check phase runs /verify-feature and reports its output verbatim). Say once, up front, that you're running inline and how to install the bundled agents. If stack.md#fix_agent is set, prefer it over the generic builder — it knows the framework.

Steps

  1. Branch. Check the current branch against vcs.md#branch_pattern. If it already matches, stay on it and say so. Otherwise run /start-issue to create one. Never create a second branch mid-loop.
  2. Brief. Write a one-line brief: goal, files in scope, definition of done. The definition of done is "every gate in quality-gates.md#gates passes" plus whatever the task itself requires. Show the brief before starting — a wrong brief burns every cycle after it.
  3. Companion knowledge (optional). Read topology.md#role.
    • If full-stack or standalone, or topology.md is missing → skip this step entirely. Say nothing about companions.
    • If frontend or backend → decide whether this task needs knowledge from the other half (API contracts, OpenAPI/DTO shapes, auth, screen flows, copy, feature flags owned elsewhere). If the brief is fully answerable inside this repo, skip.
    • When needed: open the companion at companion.path if it exists on disk; otherwise use companion.url (clone or browse) and say which you used. Pull only what the brief requires into a short "companion notes" addendum on the brief. Do not edit the companion repo unless the user asked to.
    • frontend → companion is the API (kind: api). backend → companion is the UI (kind: ui). If path and url are both empty, ask once for the location, then continue.
  4. Build. Dispatch the builder with the brief (plus companion notes, if any). On later cycles, dispatch it with the checker's failure report instead, unchanged — do not re-fetch companion knowledge unless the failure shows the prior notes were wrong or incomplete.
  5. Check. Dispatch the checker. It runs /verify-feature and returns either ALL GREEN or FAILED with one line per cause.
  6. Branch on the result.
    • ALL GREEN → go to step 8.
    • FAILED → go back to step 4 with the failures.
  7. Count out loud. Announce the cycle number before each build ("cycle 2 of 5"). Stop at loop.max_cycles.
  8. Finish. On green, stop and show the result: what changed, which gates ran, and anything skipped (including whether companion knowledge was used).
    • If stack.md#qa_mode is none, skip local QA.
    • Otherwise ask whether /qa-local is needed; if yes, run it (fixes that surface there go through the same builder/fix_agent path — do not reopen the build cycle unless the user asks).
    • Then offer /finalize-feature — do not commit, push, or open a PR on your own. A loop that pushes unattended turns a wrong brief into a wrong PR.

Stop conditions

Stop immediately, before the budget is spent, when:

  • The same failure appears in two consecutive checker reports. The builder isn't converging; more cycles won't help. Report the stuck failure and hand it back.
  • The builder reports it can't make the change (missing dependency, ambiguous requirement, a decision that isn't yours to make).
  • A fix would require weakening a check — deleting a test, loosening a lint rule, lowering a coverage threshold. Surface it and ask; never let the loop earn its green that way.
  • The task turns out to need a decision the brief doesn't cover. Ask rather than guess, then resume.

When loop.max_cycles is exhausted, follow loop.on_exhausted:

  • stop-and-report (default) — stop, show the last failure report and what was tried.
  • ask — show the same, then ask whether to spend more cycles.

Either way, leave the branch and working tree intact. The point of stopping is that a human looks at it.

Keep looking

Skills are one crate of 627,801. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.