loopkit: a drop-in .claude harness that enforces plan, act, verify with files on disk

A working loadout, not a methodology

loopkit is a drop-in `.claude/` harness and a library of small skills for coding agents. The README is blunt about what it is: straight from the author's own `.claude/` directory, the loadout they actually reach for, not a methodology, not a lifecycle, not a framework. It enforces a plan, act, verify shape with files on disk.

The user is someone running Claude Code, Cursor, Codex or Gemini who wants a sensible default setup, settings, hooks, a verifier subagent and a loop runner, without adopting a heavyweight process. The pitch is that skills load only when a task triggers them, so the agent specializes instead of guessing, and every skill is a plain markdown doc with a YAML header, nothing agent-specific in the body.

The README is equally clear about what it is not: no new methodology to learn, no daemon or server, no runtime state. It says `run.sh` is 8 lines, and invites you to fork it, gut it, and keep the three skills you like. That anti-framework framing is the whole personality of the project, and it is MIT.

Plan, act, verify, enforced by files

The loop is a simple cycle: plan leads to act leads to verify, with a revise path back to plan. What makes it more than a diagram is that the harness enforces the shape with files rather than trusting the agent to follow a prompt.

Each phase loads different skills. The README says planning skills like `spec-first`, `context-budget`, `tool-restraint` and `sprint-contract` load in the plan phase; domain skills for debug, security, testing, refactor, docs, data and git-ops load in act; and `adversarial-verify` plus `evaluator-calibration` and a verifier subagent close the loop before anything ships in the verify phase.

The verifier subagent is the load-bearing piece. Plenty of agent setups plan and act; far fewer force an independent verification step before declaring success, which is where agents most often ship something plausible and wrong. loopkit makes that a required phase driven by a separate subagent and specific skills, which is the difference between a loop that sounds disciplined and one that is.

Dropping it in and running the loop

The 30-second quickstart is a single install script that is safe on an existing project because it skips files that are already there:

curl -fsSL https://raw.githubusercontent.com/Archive228/loopkit/main/install.sh | bash

The README notes existing files are kept by default, with `FORCE=1` to overwrite or `BACKUP=1` to snapshot your current `.claude/` first. After installing, you open your agent in the same directory, write a one-line spec, and let the loop drive:

echo "STATUS: not-started" > IMPLEMENTATION_PLAN.md
./run.sh

Skills load only when a task triggers them, and the verifier subagent closes the loop. If you want just one skill rather than the whole harness, the README provides a cherry-pick command:

npx -p claude-loopkit loopkit-add adversarial-verify

That installs only the named skill into `./.claude/skills/`, with `--force` to overwrite. The design goal throughout is that this is files on disk with no runtime, so you can read exactly what got installed and remove what you do not want.

Opinionated defaults are a limitation if they are not yours

The honest limitation is that loopkit is one developer's loadout, and its value depends on that loadout matching how you work. The README is upfront that it is what the author reaches for, which is a strength for coherence and a limitation for anyone whose workflow differs. The 49 skills reflect specific opinions about planning, verification and tool restraint, and if you disagree with those, you inherit choices you did not make.

The README's own numbers even disagree slightly, the badge and text say 49 skills across 10 tracks while the short description mentions 33, so confirm the current count from the installed `skills/` directory rather than any single figure. That kind of drift is normal in a personal toolkit, but it is a reminder that this is a living loadout, not a specified product.

The cross-agent claim also has an edge: skills are plain markdown with YAML headers so they port, but the harness pieces, settings, hooks and the runner, are shaped around the `.claude/` convention, so the experience is fullest on Claude Code and thinner elsewhere. The mitigation is exactly the project's philosophy: fork it and keep what fits.

Against a heavyweight agent methodology

The alternative loopkit defines itself against is a full agent methodology, a multi-phase lifecycle or framework with its own vocabulary. The README names that contrast directly: no BMAD, no six-phase lifecycle, if a skill does not help the loop advance, it is not here.

The difference in approach is weight and lock-in. A methodology gives you structure but asks you to learn and adopt its whole model, and often a runtime to go with it. loopkit gives you files on disk, an 8-line runner and skills that load on demand, and invites you to gut it. The trade is that a methodology may offer more scaffolding for large, multi-stage projects, while loopkit deliberately stays minimal and expects you to bring your own judgement. Choose a full methodology if you want a prescribed process and are willing to learn it. Choose loopkit when you want a working default harness you can read in an afternoon, enforce plan-act-verify with a real verifier subagent, and strip down to the few skills you actually use.

MIT, no runtime, and where to start

loopkit is MIT, and its no-runtime, files-on-disk design makes it unusually low-commitment to try and to leave. There is no daemon to keep alive and no state to migrate; the harness is settings, hooks, a verifier subagent and an 8-line runner, all inspectable. Upgrades are re-running the installer, which by default preserves your existing files.

Because skills are plain markdown with YAML headers, they are portable across the named agents and easy to audit or edit, and the cherry-pick installer lets you adopt individual skills without the whole floor. That structure is what backs the fork-it-and-keep-three-skills invitation.

The concrete first step is to try it on a real but small task: run the install script, which safely skips existing files, write a one-line `IMPLEMENTATION_PLAN.md`, run `./run.sh`, and watch whether the verifier subagent actually blocks a bad result before it ships. If the plan-act-verify loop and the verification gate fit how you want the agent to behave, adopt the harness; if only a couple of skills appeal, use `loopkit-add` to take just those.

Editorial conclusion

Adopt loopkit if you want a coherent, MIT-licensed default harness for a coding agent that enforces plan, act, verify with files on disk and a real verifier subagent, and you are comfortable it reflects one developer's opinions: the enforced verification phase is the reason to reach for it over an unstructured setup. It is the wrong choice if you want a prescribed, heavyweight methodology, or if the .claude-shaped harness pieces will not fit your non-Claude agent, where only the portable markdown skills carry over. Start by running the install script on a small task, since it safely skips existing files, then run ./run.sh and confirm the verifier subagent blocks a bad result before shipping; if only a few skills appeal, cherry-pick them with npx -p claude-loopkit loopkit-add.

Frequently asked questions

Official sources

1. Archive228/loopkit on GitHub
2. Issues
3. License: MIT
4. README