The readiness skill
The book is written for you to read first. This is the companion you put to work afterwards: a skill that turns the framework on your own team instead of on a single task. It reads the live book, then sits you down and works through how much loop you can actually carry here, which loop sizes are available to you in this codebase, and the one constraint gating the next size up. What you get back is a readiness verdict. Sometimes that verdict is a plain “loose is not available to you here yet”, when that is the honest read. Never a score, a level, or a maturity badge.
Point your agent at the repo
The skill lives in the project’s GitHub repository, in its own folder. Hand any capable agent that folder and ask it to install the skill it finds there. It works in any HarnessThe scaffold that turns a model into an agent, assembled from many parts. Among those: the loop it works in, the tools it can reach, how its context is managed as a run grows long (compression, retrieval), the hooks that fire on what it does, subagents, and guardrails. Backpressure and other resistance attach here, and beyond it.An interactive agent tool like Claude Code, Codex, or Pi is a harness. You have been working inside one all along. that can read a URL.
Install this skill: https://github.com/youngbrioche/elastic-loop/tree/main/goodies/elastic-loop-readiness
A few prompts to get going
Install it. Point your agent at the folder and let it take the skill from there:
Read https://github.com/youngbrioche/elastic-loop/tree/main/goodies/elastic-loop-readiness and install the skill you find there.
Then run the diagnosis, and say who you are so it grills the part of the loop you can actually speak to:
Run an elastic-loop readiness diagnosis with me. I am a product owner on a team that has started letting agents touch our codebase.
Or skip the self-report and let your own session history set the baseline:
Analyze my last 100 sessions in this project, take that as a starting point from an individual team member and start diagnosing our elastic loop readiness.
Or aim it straight at a doubt you already carry:
We let agents do the work but never merge without reading every line. Where are our loop sizes a choice, and where are they an accident?
Or install it as a Claude Code plugin
If you are in Claude Code, there is a native path. Add the marketplace, install the plugin, reload:
/plugin marketplace add youngbrioche/elastic-loop
/plugin install elastic-loop-readiness@elastic-loop
/reload-plugins
Then ask for a loop-readiness diagnosis and Claude picks it up, or run it directly with /elastic-loop-readiness:elastic-loop-readiness. That is not a typo: the command reads plugin:skill, and here the plugin and the skill carry the same name.
Run it with the team, not for the team. Get the people who see different stretches of the loop into one room: an engineer, a product owner, a domain expert. Where they disagree about how far to let go is half of what you came for, because that disagreement is where the team’s trust actually sits. One person quietly filling it in for everyone else gets a tidy answer and skips the conversation that was the point. A single seat’s view is still worth having. It just sees one stretch of the loop and misses the rest.
One thing to keep in mind, because the framework turns on it: the skill running on your team is itself a loop. Its read is a strong first draft to argue with. The judgment about whether it holds is still yours.