Loop Library and the Loopy Skill: Bounded Agent Workflows With a Real Stop Condition
A library of practical AI-agent loops and an installable skill for finding, adapting, and designing repeatable agent workflows.
At a glance
- What is it?
- Forward-Future/loopy splits into a public catalog of agent loops and an installable skill that finds, audits, adapts, and runs them. The interesting part is not the loop idea itself but the stopping rules and the permission boundary around them.
- Who is it for?
- Adopt Loop Library and Loopy if your agent work involves repeated passes over the same target (test coverage, production errors, documentation drift) and you want each pass to carry a check, a stop condition, and a handoff point. Do not adopt it if you need scheduled or autonomous execution: the README states Loopy does not quietly start schedules, change production, publish content, or send messages, so anything that must fire without a human in the loop belongs elsewhere.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem Loop Library Targets: One-Shot Prompts That Cannot Judge Their Own Output
A prompt like "make this website faster" gives an agent no way to know whether the last change helped. The README draws this contrast directly: a loop instead says to find the slowest page, make one focused improvement, measure again, keep the change only if it helps, and repeat until every page meets the target or another pass stops producing a meaningful improvement. That is the whole thesis. The project exists because agent work that requires iteration tends to fail in one of two ways: the agent guesses at progress, or it never stops. Loop Library addresses both by treating a loop as a playbook with feedback built in, and by requiring four answers before a loop qualifies. What is the agent trying to accomplish. How will it know whether the latest attempt worked. What should it do with what it learned. When should it finish or ask for help. The audience is engineers who already run agents on recurring work such as fixing production errors, improving test coverage, reviewing a product, or keeping documentation current. It is not aimed at people who want an agent to write a single function and stop.
Two Parts, Two Delivery Mechanisms: A Static Catalog and an Optional Skill
The repository contains a website and a skill, and the README is explicit that these are separate. The website is the library: a public catalog where people and agents browse published loops, read them, and copy their prompts, with no installation required. Its code sits under loop-library/, split into a shell in loop-library/site/ and a database plus rendering layer in loop-library/worker/. The Loopy skill is the companion, sourced from skills/loopy/, and it helps an agent discover, find, audit, repair, craft, run, debrief, save, or prepare loops for publication. The distinction matters for adoption because the two halves have different failure modes. Installing Loopy does not install or host the website, so a broken catalog endpoint degrades the skill's recommendations without breaking the skill itself. Conversely, an agent with no Loopy installed can still consume the catalog through four published surfaces: an agent guide, an llms.txt instructions file, a JSON catalog, and a plain-text catalog. That design choice keeps the library usable by any agent that can fetch a URL, which is a lower bar than the skill's platform-specific install.
The Mechanism: Feedback, a Check, and a Stop Condition
Each published loop, per the README, tells an agent what to do, how to check its work, what to try next, and when to stop. That four-part structure is the mechanism, and it is deliberately shallow. There is no scheduler, no state machine, no orchestration daemon described in the material. The loop is a document that an agent reads and follows, which is why the same loop can be reused by another person or agent without rebuilding the workflow. The README frames the benefit as making work easier to trust and repeat: the agent compares results instead of relying on confidence, keeps improvements instead of merely making changes, and stops when it succeeds or stops making progress. The material also states plainly that loops are not permission to run forever, and that the best ones are bounded with a real check, a clear stopping point, and a moment to hand control back to a person when judgment or approval is needed. That last clause is the design constraint most worth testing. A loop whose check is weak will either stop too early or keep passing work that does not meet the target, and the README acknowledges this by including audit as a first-class Loopy path: audit an existing loop for weak checks, unsafe actions, or unclear stopping behavior, then repair only the material problems.
Installing Loopy: Commands, Flags, and What Each One Changes
Installation requires Node.js and npx. The per-platform commands are npx skills add Forward-Future/loopy --skill loopy --agent codex -g -y, the same with --agent cursor, and the same with --agent claude-code. To install for all three at once, the README gives a single command that repeats the --agent flag three times. For other agents, npx skills add Forward-Future/loopy --skill loopy -g runs an interactive installer that detects available agents. The flags are documented individually: -g makes the skill available in all projects and omitting it scopes the install to the current project, while -y accepts install prompts and omitting it lets you review choices interactively. That scoping choice is the one to think about before running anything. A global install puts Loopy in every project you open, including repositories where an agent following loop instructions is not what you want. Invocation differs by platform. In Codex you type /skills, choose Loopy, then enter your request, or mention it directly with $loopy. In Cursor you type / in Agent chat, search for loopy, and select it, or type /loopy directly. In Claude Code you type /loopy followed by your request. The README notes that these agents can load Loopy automatically when a request clearly calls for it, but that explicit invocation is the most predictable way to start, and that a running agent may need a restart before the skill appears.
The Permission Boundary Is the Feature, and It Is Also the Ceiling
The README states that Loopy does not quietly start schedules, change production, publish content, or send messages on your behalf, and that those actions still require the normal permissions and approvals. This is the project's clearest limitation and its clearest virtue, depending on what you need. If your use case is an agent that remediates production incidents unattended, Loopy is the wrong tool by design. It will run a loop in bounded passes and return a receipt with the actions, evidence, outcome, and stopping reason, but the receipt is a report, not an execution guarantee. Publication follows the same pattern: Loopy can check a loop for catalog overlap, prepare a publication draft, and submit it only after you approve the exact preview. Saving is similarly gated, with loops written into the project's LOOPS.md when you ask and reused in later sessions. A second limitation is naming drift. The previous loop-library skill name remains available as a compatibility alias, and the README directs new installations to use loopy. Teams with existing automation that references the old name should confirm which name their agents resolve before changing anything. A third gap in the supplied material: no releases were retrieved, so there is no version history to reason about, and the README excerpt ends mid-table during the description of Loopy's nine paths, meaning the full path list cannot be confirmed from what is available here.
Alternatives: A Catalog Plus Skill Versus a Framework That Owns the Loop
The obvious alternative to Loop Library is an agent framework that implements iteration in code rather than in a document. LangGraph, for example, models agent work as a graph of nodes with explicit edges and conditional routing, so the loop's stop condition is a branch in your program that you can unit test, version, and debug with a stack trace. Loop Library takes the opposite approach. The loop is prose that an agent interprets, which makes it portable across Codex, Cursor, and Claude Code without writing platform-specific code, and lets a human read and edit the loop in a text file. The trade-off is real in both directions. A graph-based framework gives you deterministic control and observability but ties the workflow to that framework's runtime. A prose loop travels anywhere an agent can read text but depends on the model's judgment to honor the stop condition, which is exactly why the README treats auditing for weak checks as a core capability rather than an afterthought. If your loop must run identically a thousand times, encode it. If it must be understood, adapted, and shared by different people and different agents, a document is the lighter artifact.
Maintenance Cost and the MIT Licence
The repository is MIT licensed, which permits commercial use, modification, and redistribution provided the licence text and copyright notice are preserved. That is a permissive baseline, and it applies to the skill source under skills/loopy/ and the website code under loop-library/. No legal advice here: if you fork the catalog or republish loops, read the licence text in the repository rather than this summary. On maintenance, the material supports a few concrete observations. The project was last pushed on 2026-07-26 and is not archived, so it is active as of that date. No releases were retrieved, which means there is no tagged version to pin against, and installation pulls from the repository's default branch via npx skills add. That is the practical cost: an unpinned install can pick up changes without a version boundary. The skill also has an external dependency at runtime, since Loopy checks the live catalog when it recommends a published loop. If signals.forwardfuture.com is unreachable, recommendation quality degrades even though the skill is installed locally. Teams that need reproducible installs should pin to a commit rather than trusting the default branch, and should decide deliberately whether -g belongs in their setup.
Editorial conclusion
Adopt Loop Library and Loopy if your agent work involves repeated passes over the same target (test coverage, production errors, documentation drift) and you want each pass to carry a check, a stop condition, and a handoff point. Do not adopt it if you need scheduled or autonomous execution: the README states Loopy does not quietly start schedules, change production, publish content, or send messages, so anything that must fire without a human in the loop belongs elsewhere. Before installing, verify that the catalog endpoints at signals.forwardfuture.com/loop-library/catalog.json and catalog.txt resolve, and confirm which of the nine Loopy paths your agent platform actually surfaces after install, since the README warns that a running agent may need a restart before the skill appears.
Community notes