The AI Builder Club skills plugin ships two of the four ingredients a loop needs

The four ingredients of a loop are enumerated, and this repository supplies two

The concept behind the plugin is a shift from prompting a coding agent one task at a time to designing loops. A loop is defined as an agent that wakes up on a trigger, does investigation and work, and writes what it found and what it did into a shared, file-based memory, so the next run reads that memory and keeps going instead of starting over.

Building one is broken into four ingredients. Triggers, meaning cron, a webhook, an incident or another agent. A file and logging structure, which is the shared memory loops read and write, attributed to the `loops` skills. Tools and connectors, so the agent can do real work through your own skills and MCPs. And a codebase harness, so the agent can run, test and verify its own work, attributed to the `codebase-harness` skills.

Then the honest sentence: this single `skills` plugin ships both sets, giving you number 2 and number 4, plus the scaffolding to add the rest. Triggers and connectors are named as requirements and left to you. Anyone evaluating this as a loop platform is evaluating half of one.

There is no LICENSE file in the tree, no release, and no version to pin

The repository root holds six entries: `.claude-plugin/`, `.gitattributes`, `.gitignore`, `README.md`, `assets/` and `skills/`. No licence file is among them, and the repository's licence field comes back unset rather than naming a standard licence.

There are no GitHub releases either, so there is nothing to pin, compare or roll back to. The last push to the default branch is dated 2026-09-15.

Installation is a pair of slash commands against the marketplace rather than a versioned artifact:

/plugin marketplace add AI-Builder-Club/skills
/plugin install skills@ai-builder-club

The install therefore resolves to whatever is on the branch at the moment you run it. That is normal for a plugin marketplace, and it becomes a problem when the same repository tells you it will audit your agent context against a specific model generation's guidance. You get the current rules, not the rules as they were when the advice you read was written.

`/new-loop` writes into `CLAUDE.md` and creates four things on its first run

The second entry point is `/new-loop`, and it is where the design becomes concrete. You run it where the agent's memory should live. On the first run it bootstraps a knowledge base, creating `ARCHITECTURE.md`, `LOG.md`, the `signals/`, `docs/` and `domains/` folders, and a knowledge-base section in your `CLAUDE.md`. It then scaffolds the loop, does one real test run, and logs it. Running it again later adds another loop.

Two things follow from that. First, the tool edits the file your coding agent reads at the start of every session, without asking which section to put it in. Second, the compounding model depends on many loops writing to the same folders: the stated example is that 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.

So several concurrent agents appending to one `LOG.md` is the normal case, not the edge case. The repository is aware of this shape elsewhere, since its delegation skill uses a race-safe done-signal protocol, but the knowledge base layout itself is presented as plain files with no locking.

`crabbox-setup` says one laptop cannot run N, so parallel shipping means cloud boxes

The harness has five skills and one master. `setup-codebase-harness` orchestrates the other four and pulls in only what the repo needs, which means the choice of what to install is made by an agent reading your repository rather than by you.

`dev-local-setup` is the local half: it produces a one-command local dev stack driven by `scripts/dev-local.sh up`. `e2e-setup` is for repos with no or weak end-to-end coverage, adding a real per-PR test gate.

`crabbox-setup` is the part with a bill attached. Its stated purpose is giving each agent its own isolated cloud stack so loops can ship code in parallel, and the reason given is blunt: one laptop cannot run N. It is described as the cloud counterpart to the local setup skill. So the parallel-shipping story, which is the whole argument for a loop engineer, is the one part of the harness that cannot run on your own machine.

Note also what the plugin does not claim: it supplies the harness, not the trigger, so something else has to decide when a box should be created, used and torn down.

`verifier-setup` has a fresh sub-agent drive the app and open the pull request

The fifth harness skill scaffolds a repository-specific `/verify` skill rather than doing the verification itself. The division of labour is worth spelling out, because it is unusual: a fresh sub-agent drives the running application, captures screenshot or video proof, and opens the pull request with that proof embedded.

So the agent that verifies is not the agent that wrote the change. It starts clean, sees the app as a user would, and produces artefacts rather than assertions. That is a real answer to the problem of an agent marking its own work as passing.

The dependency order matters too. The skill first ensures that the local dev stack and the browser driver exist, which means verification is gated on a browser driver being installed on the host. On a machine without one, `/verify` is not merely degraded; its first action is to install a prerequisite.

Combined with `e2e-setup` adding a per-PR gate, the harness can end up with two independent checks in front of every pull request, one scripted and one agent-driven with attached visual proof.

One plugin, three platform assumptions: Pillow locally, MLX Whisper for video, tmux for delegation

The standalone utility skills do not share an environment. `visual-flow-gif` turns an article, workflow or architecture into a static PNG plus an animated GIF, going from a JSON spec through a local Python and Pillow renderer.

`karaoke-captions` burns word-level highlight captions into a video through a three stage pipeline: MLX Whisper for transcription, then ASS subtitles, then FFmpeg with libass. MLX is Apple hardware, so that path is not portable to a Linux CI runner without being rewritten.

`open-agent-teams` delegates tasks to any CLI agent, naming claude, codex, grok and aider among the options, each running in a detached tmux session. It adds a race-safe done-signal protocol, multi-turn iteration, and a delegation-rules template for `CLAUDE.md` that separates coordinator and executor roles.

Three platforms in one plugin: a local Python renderer, an Apple-specific speech model, and a Unix terminal multiplexer. Installing everything at once, which is what the documented install command does, means you take on the union of those requirements even if you use one skill.

`agent-context-audit` judges your context against a named model generation, then applies the fixes

The context skill audits a repository's agent context, meaning `CLAUDE.md`, codebase docs, skills and tool or MCP designs, against Anthropic's Claude 5 context-engineering guidance. It reports five categories of finding: overconstraint, conflicting instructions, redundancy, stale facts and missing gotchas. Findings come with concrete rewrites, and then approved fixes are applied.

The taxonomy is the useful part. Overconstraint and conflicting instructions are the two failure modes that make an agent slower rather than wrong, and stale facts are the one that survives review because the file still looks authoritative.

The two things to weigh are the baseline and the write access. The baseline is pinned to a named model generation while the plugin has no releases, so the guidance moves under you. And the skill does not stop at a report: it rewrites your context files once you approve, which makes it the one skill here that changes how every future session behaves.

The only number in the repository is a seven day result inside the SEO playbook

`seo-growth` is described as two playbooks, one for a cold start with no rankings and no authority, and one for an existing site with data. It is said to be distilled from two content properties run in production, and it ships a loop template so it can run on a schedule.

The specific claim inside it is the emerging-term method, which is credited with taking a brand-new pillar page to the site's most-clicked page in 7 days. The same passage mentions the failures that cost the authors a head term.

It is worth being clear about what that is. Seven days on a named site is the only quantified outcome anywhere in this repository, and nothing in the tree records the starting rankings, the terms involved or the traffic before and after. The skill is a distillation, and a distillation is a reasonable thing to ship; it is not a measurement you can check.

The scheduling part is more concrete than the result. Shipping a loop template ties the playbook to the same trigger-plus-shared-memory model as the rest of the plugin, which means the SEO loop is one more writer into the common knowledge base.

Editorial conclusion

Take this plugin if you already know how you want an agent loop triggered and you want help with the half of the problem that is pure plumbing: a repo that can run, test and verify itself, and a knowledge base layout the next run can read. Do not take it expecting a turnkey loop system. Check four things first. There is no licence file and the repository's licence field is unset, so decide with the authors what terms you are working under before you let a skill edit your files. There are no releases either, so the marketplace install is whatever is on the branch. Note that three skills assume three different environments, tmux for delegation, MLX Whisper for captions and paid cloud boxes for parallel shipping. And remember the first run of `/new-loop` writes into `CLAUDE.md`, which every later session reads.

Frequently asked questions

Official sources

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