Put the skills in a loop
This tutorial builds the smallest honest software factory: a loop that improves your codebase while you sleep and asks for your sign-off in the morning. It pairs with the loop engineering guide, which explains the theory. Here you build one concretely. Keep the scope tiny on purpose, because a loop earns autonomy only where the check is cheap and hard to fake.
Pick a task that earns the dark
Help me pick one narrow, high-frequency, hard-to-fake improvement to automate: for example, fixing a single lint violation or removing one needlessly optional prop per run. It must be verifiable by a green-or-red check. You and the agent choose a change whose "done" a machine can prove, not just assert.
Back pressure: automate only what you can cheaply and reliably verify. A cheap oracle is what lets you walk away safely. See the loop engineering guide for where to keep the lights on.
Define the maker
Write a short instruction for a "maker" agent: find one instance of the target pattern, fix it following incremental-implementation and test-driven-development, run the tests and linter, and commit only if both pass. You capture the inner-loop worker as a small, repeatable instruction (a prompt or a SKILL.md).
The maker is one job on repeat: gather context, act, check, commit. Writing it down once is what turns a one-off run into a loop.
Add a separate checker
Write a "checker" agent that reviews the maker’s diff with code-review-and-quality against a short rubric, and rejects anything outside the target pattern or larger than a few lines. A second agent, with different instructions, grades the work the maker produced.
The model that wrote the code grades its own homework too kindly. A separate checker is the only reason you can trust an unattended run. This is the same split /ship uses.
Wrap it in a loop with a real stop condition
Set this up to run on a schedule with a verifiable stop condition. In Claude Code use /loop or a run-until-done /goal such as "tests and lint are clean"; in Codex use an Automation. Keep each run to one fix. A harness primitive (Claude Code /loop or /goal, or a Codex Automation) runs the maker and checker on a cadence.
The loop primitive belongs to your harness, not this pack. It runs the skills, and a separate model, not the maker, decides when the run is done.
Give the loop a memory
Add a state file (a progress markdown file or a tracker) where each run records what it changed and what is left, so tomorrow’s run resumes instead of repeating itself. The loop writes what it did to disk, outside any single conversation.
The model forgets everything between runs. The state file is the spine that lets the loop pick up where it stopped.
Make the loop hand you evidence
Have the loop open a small pull request with the diff, the passing test and lint output, and a one-line rationale. Anything it cannot verify should be left for me, not merged. Each successful run produces a short, reviewable PR; anything uncertain is escalated, not shipped.
This is the boundary between the inner and outer loop. What crosses it is evidence: a diff, green checks, and a reason. You give the verdict.
Own the outer loop
Review the loop’s PR. Decide: merge, redirect, or turn the loop off. Then decide which parts of your codebase should never run lights-out (auth, billing, public APIs) and keep those on manual review. You read the evidence, make the call, and set where the loop is allowed to operate.
The agent can ship more than you can review, so your judgment is the scarce resource. You stay in the constraints, sampling, audit, and ownership loops. The loop cannot inherit the consequences. You can.
A tiny, honest software factory: a scheduled maker-checker loop that improves the codebase and hands you a short PR to approve, with the risky parts of the system kept firmly on manual review. Scale the pattern only as far as your verification can reach.