Your output won't scale
if you're in every
little loop
little-loops imagines Software Engineering as the art of crafting simple machines that run themselves. A loop to discover bugs. A loop to score results. A loop to write code that feels inevitable. A loop made of these loops.
pip install little-loops
ll-initYou were promised
exponential output.
You got
babysitting chat windows.
What if...
// designed to run without you
Wind it up. Let it run.
A loop is a small machine you define once and run forever. Describe what to check, what to fix, and when to stop — little-loops compiles it into a finite state machine and hands it to your host CLI. No babysitting. No streaming output to watch. Just a goal and a done condition. Three guarantees run underneath every loop: durable state, consistent process, and harness-gated verification.
Never write a disposable prompt again.
Start from a conversation, a pattern you keep repeating, or a blank slate.
/ll:create-loopInteractive wizard — answer a few questions, get a YAML loop file.
/ll:loop-suggesterMines your session history for repeated workflows and proposes loops that would automate them.
Durability
The run outlives the chat.
State checkpoints to disk after every FSM transition. Crashes, context resets, Ctrl-C — ll-loop resume picks up mid-trajectory, exactly where it stopped. When one context window fills, agents hand off to a fresh one. Nothing is lost.
Consistency
The toolbelt is the process.
Same feature, same shape, every run. Context gathering, issue lifecycle, sprint moves, worktree setup, and branch naming run as typed ll- commands. Harnessed skills compose them into a fixed plan → implement → verify → complete sequence. The agent reasons inside steps, not about which steps to take.
Verification
The harness is the spec.
Every iteration is graded against a runnable evaluation — exit codes, output patterns, numeric metrics, LLM judges, or full agentic simulations of the real product. Failures route back into execution, not forward into your codebase. See Automatic Harnessing →
Context that travels with your code.
Issues in little-loops aren't tickets in an external system. They're structured Markdown files in your repo — capturing root cause, integration map, and acceptance criteria that double as the verification spec for the loop that implements them. A well-formed issue gives the agent exactly what it needs to make a correct, focused change; a vague one leads to guesswork.
Context is the difference between a guess and a fix.
A raw “fix the login bug” prompt leads to guesswork. A well-formed issue with a root cause analysis, integration map, and implementation steps gives the agent exactly what it needs to make a correct, focused change.
add search maybe filter by name or date?
## Summary Add full-text search to the issues list with filtering by name, priority, and date range. ## Root Cause No search index or filter state in the issue list component. ## Integration Map - src/components/IssueList.tsx — add search state + filter logic - src/hooks/useIssues.ts — extend with search/filter params - src/api/issues.ts — add query params to the list endpoint ## Acceptance Criteria - [ ] Search returns results within 200ms - [ ] Priority filter supports multi-select - [ ] Empty state shown when no results match
Agents climb any mountain with the right harness
The best feedback loop is the product itself. Automatic harnessing wraps any skill, command, or MCP tool call in a layered evaluation pipeline — from fast exit-code checks to full agentic simulations where Claude uses the feature end-to-end. Generate harnesses interactively with a guided wizard or let little-loops derive them from your project.
Turn your tools into agent rules, in one command.
A harness isn't limited to running tests. It can wire together anything your project has:
Skills
Invoke any little-loops skill as an evaluation step. Refine an issue, check code quality, audit docs — then evaluate whether the skill's output actually met the bar.
MCP Tools
Call external services directly. Query a database, screenshot a page, check that a GitHub PR was created. Any MCP server you've connected becomes an evaluation gate.
CLI Commands
Any shell command that returns an exit code. Your test suite, linter, type checker, a custom validation script. If it exits 0, it passes.
One issue or thirty. Your call.
Refined issues go in. Committed code comes out. Choose sequential for simplicity, parallel for speed, or sprint for coordinated execution across dependency graphs.
Sequential. Predictable. Fire and forget.
Picks up every ready issue in priority order and works through them one at a time. Deterministic execution — each issue completes before the next begins. Great for auditable, reviewable batch work.
ll-auto
ll-auto --max-issues 5
ll-auto --resumeTwo commands to start.
ll-init auto-detects your project type — Python, JS/TS, Go, Rust, Java, .NET, or generic — infers your test and lint commands, scaffolds .issues/, and writes .ll/ll-config.json. Run it bare for the interactive wizard, or ll-init --yes to accept the detected defaults.
Requires Python 3.11+ and Claude Code (the default host CLI)
# 1. Install the CLI tools
pip install little-loops
# 2. Initialize your project (auto-detects your stack)
ll-init# 3. Add the plugin inside Claude Code for the /ll:* commands
/plugin marketplace add BrennonTWilliams/little-loops
/plugin install ll@little-loops
# 4. Sanity-check your setup
ll-doctorUsing Codex or Kimi Code instead? Run ll-init --hosts codex and ll-adapt --host codex --apply.