Autonomous Development Toolkit

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.

The public package has been retired.

GitHub

You were promised

exponential output.

You got

babysitting chat windows.

What if…

agents worked~~for minutesfor hoursfor days~~until done.

// designed to run without you

01 / loops

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.

bash

/ll:create-loop

Interactive wizard — answer a few questions, get a YAML loop file.

bash

/ll:loop-suggester

Mines your session history for repeated workflows and proposes loops that would automate them.

One command. Walk away.

bash

ll-loop run fix-quality-and-tests

Your host CLI enters the FSM, runs the check, follows the transition, applies the fix, checks again — until the exit condition is met or the iteration limit hits.

Crashes, context resets, Ctrl-C — pick up exactly where it stopped.

State saves to disk after every FSM transition. Agents hand off to fresh agents when context gets long. Nothing is lost.

bash

ll-loop resume fix-quality-and-tests

fig. 01aGenerate · /ll:create-loop · /ll:loop-suggester

Scroll sideways for the full loop.

fig. 02general-task · the loop every ll-loop run executes

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

02 / issues

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.

Vaguevague fix

add search maybe filter by name or date?

Structuredworking fix

## 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

Surface bugs, dead code, and architectural gaps automatically.

bash

/ll:scan-codebase

Research the actual codebase to fill in root causes, affected files, and concrete implementation steps.

bash

/ll:refine-issue

Validate that every issue is complete, specific, and has no open questions before any code gets written.

bash

/ll:ready-issue

Issues that pass the gate are ready for autonomous implementation. No ambiguity. No guesswork.

fig. 03aWhy · a vague prompt beside a refined issue

03 / automatic harnessing

Agents that check their own work

The best feedback loop is your actual product. Harnesses let agents verify what they built — running your tests, using the real UI, checking that the feature actually works — before calling it done. No more reviewing code that was never tested.

Wire up any check you already trust.

A harness can include anything that tells the agent “this worked” or “try again”:

Your Test Suite

Run your tests, linter, or type checker as a verification step. If the checks pass, the agent moves on. If they fail, it iterates.

External Services

Query a database, screenshot a page, confirm a PR was created. Any tool your project already uses can become a verification gate.

Custom Scripts

Any script or command that signals pass/fail. Validation logic you've already written plugs right in.

Try multiple approaches. Review only the winner.

Instead of implementing one solution and hoping it's right, harness multiple candidates against the same checks. The agent evaluates each approach — you review the one that actually passed.

bash

ll-loop run harness-single-shot

Same loop engine. Same resilience. Same walk-away confidence.

fig. 04aVerify · tests, services, and scripts as gates

04 / implement

One issue or thirty. Your call.

Refined issues go in. Committed code comes out. Pick the execution style that fits — one at a time, many at once, or a full coordinated sprint.

Predictable. Reviewable. Fire and forget.

Works through your issues one at a time in priority order. Each issue completes and commits before the next begins — easy to review, easy to audit.

bash

ll-auto

Multiple issues. No conflicts. Same clock.

Runs several issues simultaneously, each fully isolated. No shared state, no merge conflicts. Dramatically faster when issues don't depend on each other.

bash

ll-parallel --workers 4

Dependency-aware. Wave-based. Coordinated.

Group related issues into a sprint. little-loops figures out what depends on what and executes in waves — independent work runs in parallel, dependents wait for their prerequisites to finish.

bash

ll-sprint run sprint-1

Example sprint plan

Wave 1 (parallel):
- FEAT-001: Add middleware layer
- BUG-010: Fix null check in parser
Wave 2 (after Wave 1):
- FEAT-002: Extend middleware config
- FEAT-003: Update middleware tests
Wave 3 (after Wave 2):
- FEAT-004: Integration tests for middleware

fig. 05aSequential · ll-auto

05 / install

The public package has been retired.

little-loops has been deprecated as a public project. The install commands that used to appear here no longer work.

Status

Public package retired.

The little-loops package on PyPI, the Claude Code plugin install and the public documentation are no longer available.

fig. 06Install · retired

We are focusing fully on little-loops 2. It is coming soon.

GitHub

Your output won't scale if you're in every little loop

Never write a disposable prompt again.

One command. Walk away.

Crashes, context resets, Ctrl-C — pick up exactly where it stopped.

Context is the difference between a guess and a fix.

Surface bugs, dead code, and architectural gaps automatically.

Research the actual codebase to fill in root causes, affected files, and concrete implementation steps.

Validate that every issue is complete, specific, and has no open questions before any code gets written.

Wire up any check you already trust.

Test against the real product, not just assertions.

Try multiple approaches. Review only the winner.

Predictable. Reviewable. Fire and forget.

Multiple issues. No conflicts. Same clock.

Dependency-aware. Wave-based. Coordinated.