AI-Builder-Club/skills: A Claude Code Plugin Marketplace for Agent Loops and Codebase Harnesses

The problem: prompting an agent task-by-task does not compound

The README frames the shift directly: you stop prompting a coding agent task-by-task and start designing loops. A loop, as defined here, is an agent that wakes on a trigger (a cron, a webhook, an incident, or another agent), does investigation and work, then writes what it found and did into a shared, file-based memory. The next run reads that memory and continues. The stated goal is compounding: many loops (support, SEO, product, ads) read and write the same folders, so a friction the support loop logs can be picked up by the product loop, and a keyword the ads loop finds can feed the SEO loop. This is a specific audience: teams already using Claude Code who want their agents to run on a schedule or on events, not just when a human types a prompt. The repository does not claim to be a general agent framework. It is a plugin marketplace of skills, distributed through Claude Code's plugin system, and the README says it is the productized version of the setup the author's team runs in production.

What the plugin actually ships: two flagship skill sets and four utilities

The single skills plugin ships both flagship sets, which the README maps to ingredients #2 (a file and logging structure) and #4 (a codebase harness) of the four-ingredient loop recipe. The codebase harness set contains five skills: setup-codebase-harness orchestrates the other four; dev-local-setup provides a one-command local dev stack (scripts/dev-local.sh up); e2e-setup adds a per-PR test gate; crabbox-setup gives each agent its own isolated cloud stack for parallel shipping; and verifier-setup scaffolds a repo-specific /verify skill in which a fresh sub-agent drives the app, captures screenshot or video proof, and opens the PR with that proof embedded. The loops set contains new-loop, which bootstraps the knowledge base and scaffolds a loop. Four standalone utilities round out the plugin: agent-context-audit, open-agent-teams, seo-growth, and visual-flow-gif. Each has its own SKILL.md in the repository's skills directory, and the README provides direct links to them.

How the loop mechanism works: triggers, shared memory, and a test run

The design is file-based rather than database-based. Running /new-loop where your agent's memory should live bootstraps the knowledge base on first run: it creates ARCHITECTURE.md, LOG.md, and the signals/, docs/, and domains/ folders, plus a knowledge-base section in your CLAUDE.md. It then scaffolds the loop, does one real test run, and logs it. Running the command again adds another loop. The README describes four ingredients for building a loop: triggers (cron, webhook, incident, or another agent); the file and logging structure that serves as shared memory; tools and connectors (your skills and MCPs); and a codebase harness so the agent can run, test, and verify its own work. The plugin covers the second and fourth ingredients and provides scaffolding for the rest. That division matters: the trigger mechanism itself is not shipped as a component you configure inside this plugin. You still need to wire up the cron job, webhook, or upstream agent that starts each run. The verifier-setup skill's constraint is also explicit in the README: it ensures dev-local and the browser driver exist first, so verification depends on the local stack being in place.

Getting it running: two commands and two entry points

Installation is two commands, run inside Claude Code. The README gives them as /plugin marketplace add AI-Builder-Club/skills followed by /plugin install skills@ai-builder-club. There is no pip install, no npm package, and no clone step mentioned. After installation there are two entry points. /setup-codebase-harness is run in the code repository your agents work in; it orchestrates the harness skills and, per the README, you pull in only what the repo needs. /new-loop is run where your agent's memory should live; its first run creates the knowledge base files and folders listed above. The concrete artifacts you can expect from the harness side include scripts/dev-local.sh (with an up subcommand) from dev-local-setup, a per-PR test gate from e2e-setup, an isolated cloud stack per agent from crabbox-setup, and a /verify skill from verifier-setup. The visual-flow-gif skill renders a JSON spec through a local Python/Pillow renderer into a static PNG plus an animated GIF. The open-agent-teams skill delegates to CLI agents such as claude, codex, grok, and aider running in a detached tmux session, using what the README calls a race-safe done-signal protocol.

Where this is the wrong tool: no licence, no releases, and a hard Claude Code dependency

The most concrete limitation is distribution. Everything here is a Claude Code plugin, installed through /plugin marketplace add and /plugin install. If your team uses a different agent runtime, or needs a vendor-neutral orchestration layer, none of the harness or loop scaffolding is directly usable; the SKILL.md files are readable, but the entry points assume the plugin system. The second limitation is maintenance surface. The loops depend on generated files (ARCHITECTURE.md, LOG.md, CLAUDE.md, and the signals/, docs/, and domains/ folders). Those are not inert output; they are the shared memory that every loop reads and writes. A stale or contradictory entry propagates to every loop that touches it. The agent-context-audit skill exists partly because of this class of problem, since it looks for overconstraint, conflicting instructions, redundancy, stale facts, and missing gotchas in CLAUDE.md and related context. Third, crabbox-setup provisions an isolated cloud stack per agent, which the README justifies by noting that one laptop cannot run N stacks. That is a real infrastructure commitment with a cost dimension the README does not quantify. Finally, the supplied material states no licence and retrieves no releases. The repository is not archived and its last push is 2026-07-27, but a repository with no tagged releases offers no versioned upgrade path; you track the main branch or you pin a commit yourself.

Alternatives and the difference in approach

The README's own comparison point is the manual baseline: prompting a coding agent task-by-task. The difference is not tooling quality but where state lives. In the manual model, context lives in the conversation and evaporates when the session ends. Here, context lives in files (ARCHITECTURE.md, LOG.md, signals/, docs/, domains/) that outlive any single run and are shared across loops. For the delegation piece, the open-agent-teams skill is positioned against single-agent workflows: it delegates to any CLI agent (claude, codex, grok, aider) in a detached tmux session with a done-signal protocol and a CLAUDE.md delegation-rules template for coordinator and executor roles. That is a different architecture from a single agent doing everything in one context window. For context hygiene, agent-context-audit is positioned against Anthropic's Claude 5 context-engineering guidance, which it audits against. A team that only needs a local dev script or a per-PR test gate could adopt those two skills in isolation without building any loops at all, since the README states that setup-codebase-harness pulls in only what the repo needs.

Maintenance, upgrades, and licence status

There are no releases in the supplied material, so there is no changelog to read and no version to pin by tag. Upgrades mean pulling from the main branch through the plugin marketplace. The generated knowledge base is the part that ages: every loop writes into LOG.md and the signals/, docs/, and domains/ folders, and those files need periodic review or the shared memory becomes a liability rather than an asset. The agent-context-audit skill is the repository's own answer to that drift, since it reports findings with concrete rewrites and then applies approved fixes. On licensing, the supplied material does not state a licence for this repository. Before adopting it inside a company, confirm the licence terms from the repository itself rather than assuming they match the plugin marketplace conventions; this is a factual gap in the available material, not a legal opinion. The homepage at aibuilderclub.com and the linked YouTube walkthrough are commercial entry points, which is worth knowing when weighing how much of the workflow is documented in the repository versus behind the product.

Who should adopt it, and what to verify first

The fit is narrow and clear: teams already committed to Claude Code who want agents that run on triggers and accumulate findings in shared files. If you are still prompting task-by-task and your work does not repeat, the loop scaffolding adds files you will not maintain. If you need cross-runtime portability, look elsewhere; the plugin system is the delivery mechanism, not an implementation detail. Before installing, check that your Claude Code build accepts the /plugin marketplace add and /plugin install commands as written, confirm the repository's licence, and decide whether you are willing to run crabbox-setup's per-agent cloud stacks, since that is the skill with the clearest infrastructure cost. A reasonable first step is to run /setup-codebase-harness on one repository and inspect the generated files before running /new-loop anywhere, because the knowledge base is the piece every later loop depends on. The plugin's value is proportional to how many loops share the same folders; with one loop, the shared-memory design has nothing to share.

Editorial conclusion

Adopt this plugin if you already run Claude Code and want to move from prompting a coding agent task-by-task to designing scheduled or event-triggered loops backed by a shared file-based knowledge base. Do not adopt it if you need a language- or vendor-neutral orchestration layer, or if you cannot commit to maintaining the generated CLAUDE.md, ARCHITECTURE.md, and LOG.md files that the loops depend on. Before installing, verify three things: that your Claude Code version supports the /plugin marketplace add and /plugin install commands shown in the README, that the repository's licence is acceptable for your use (the licence is not stated in the supplied material), and that the skills you intend to use (particularly crabbox-setup, which provisions cloud stacks) match your infrastructure and cost constraints.

Official sources

1. AI-Builder-Club/skills on GitHub
2. Issues
3. Project website
4. README