Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add BuildGreatProducts/builder-os --skill build-loop-claude-codegit clone --depth 1 https://github.com/BuildGreatProducts/builder-osWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/buildgreatproducts/builder-os/build-loop-claude-code)<a href="https://agentmods.dev/skills/buildgreatproducts/builder-os/build-loop-claude-code"><img src="https://agentmods.dev/badge/skills/buildgreatproducts/builder-os/build-loop-claude-code/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/buildgreatproducts/builder-os/build-loop-claude-code"><img src="https://agentmods.dev/badge/skills/buildgreatproducts/builder-os/build-loop-claude-code.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- Socket pass
- Snyk pass
- NVIDIA SkillSpector pass
SkillSpector: 1 finding, up to low
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- low Excessive Agency · line 39 Skill's behavior or capabilities extend beyond its stated purpose. Scope creep allows an agent to perform actions unrelated to its documented functionality, increasing the attack surface.Fix: Limit the skill's scope to its documented purpose. Remove instructions that enable the agent to perform actions outside its stated functionality.
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00146 | $0.00777 |
| Opus 5.5 | $0.00058 | $0.00311 |
| Sonnet 5.5 | $0.00029 | $0.00155 |
| Haiku 4.5 | $0.00015 | $0.00078 |
Grade A, and why
build-loop-claude-code scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
Copies of this mod
2 near-identical copies found in the catalogue:
- build-loop-codex — 91% identical, 8 lines differ
- build-loop-cursor — 89% identical, 8 lines differ
How it starts
The opening of the file, as written. The whole thing — 40 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Claude Code Build Loop
Quality-gated feature work: nothing ships on "it compiles" — every increment is built, reviewed, tested end to end, and fixed before the user hears "done."
Source of work
- A plan file exists (roadmap, refactor plan, or task list with
- [ ]checkboxes — search the repo): work the first unchecked task. Tasks are ordered intentionally — never skip ahead. If the plan references spec docs, read only the sections relevant to the current task. - No plan (or the request is outside it): build from the user's prompt. Restate it as a verifiable goal with 2–4 success criteria and confirm scope in one message before building.
The loop
Run per task (or per prompted feature). Do not advance until every step passes.
-
Build. Implement exactly what the task specifies. Simplest implementation that satisfies it, surgical changes, no speculative scope. Match existing project conventions.
-
Review. Run
/reviewon the changed code. If the change touches auth, payments, user input, or data access, also run/security-review. Fix all findings in scope — bugs, security issues, edge cases, performance, style in files you touched. If the project has a design system spec (design tokens file, DESIGN.md, theme config), check UI changes against it — no hardcoded colors, type, or spacing that bypass tokens. Note pre-existing issues in untouched code for the report instead of fixing silently. Re-run/reviewuntil clean. If a finding contradicts the task or spec, the spec wins — flag the disagreement. -
Test end to end. Run the task's verification step (or the success criteria). Run the full test suite — everything that passed before must still pass. Add tests for new logic. Then exercise the feature as a user would: run the app, walk the real flow including empty, loading, and error states.
-
Fix. Anything testing finds goes back through the loop: fix →
/review→ re-test. Never mark a failing task complete; never start the next task with the app broken.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 40 lines · 146 tokens per session scan A c8e1422ce095
build-loop-claude-code is a skill published in the GitHub repository BuildGreatProducts/builder-os (231 stars, last pushed 3mo ago), licensed MIT. It adds 146 tokens to every session and 777 once invoked, about $0.0006 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
adk-go-self-review
Review an ADK Go change the way a maintainer will — a fresh-context pass over the whole diff, five lenses (correctness and tests, scope, simplicity, style, adk-python parity), and the mutation check that proves your tests pin the change. Use before opening a PR, before any later push that changes code, and when asked…
adversarial-reviewer
Stress-test a code change for concrete correctness defects, unsafe assumptions, and failure modes. Use when the user explicitly asks for an adversarial review, a deep bug hunt, or to tear a change apart, or to check your own change before submitting it. Do not use for ordinary review, style feedback, or general…
go-testing
Trigger: Go tests, go test coverage, Bubbletea teatest, golden files. Apply focused Go testing patterns.
semgrep-rule-variant-creator
Creates language variants of existing Semgrep rules. Use when porting a Semgrep rule to specified target languages. Takes an existing rule and target languages as input, produces independent rule+test directories for each language.
brooks-sweep
Full-sweep mode: runs a unified analysis across all quality dimensions — code decay, architecture, tech debt, and test quality — then applies fixes directly to the codebase. Safe changes are auto-applied; risky changes are confirmed before execution. Drawing on twelve classic engineering books. Triggers when: user…
plugin-review
Review plugin quality with tiered checks and dependency scoping. Use for PR and pre-release audits.