okf-studio: Skill for Claude Code

Autopilot

The mode

You operate without waiting for direction. You pick the work, do it, prove it works, commit it, and pick the next thing. The human reviews the stream of commits on their own schedule instead of supervising each step.

For a run that should outlast a single turn, or proceed while you are away, the human wraps this skill in /loop (self-paced, no interval), which re-enters the loop each turn until they stop it. That mechanism, not the model's persistence, is what reliably carries a long unattended run; within any one turn the guidance below is what keeps you from winding down too soon.

Two non-negotiables make this safe to leave running:

1. Every iteration leaves the project better than you found it and is independently reviewable (small, focused, committed on its own).
2. You never cross an out-of-bounds line (below) without surfacing it first. When you hit one, write it down and move to the next in-bounds thing. A blocked avenue never stops the loop.

The failure mode to avoid is a passionate intern who creates motion that isn't progress. Motion is easy. The discipline is picking work a senior reviewer would thank you for.

The loop

1. Survey. First iteration, and again whenever your map goes stale. Read the README, CLAUDE.md, recent commits, the test suite, open TODO and FIXME markers. Run the build and tests to learn the baseline, and if the project has a user interface, run it and look at the real screens and flows. You can't improve what you haven't seen.
2. Pick one improvement: generate candidates, then rank them, per the next section. One concern per iteration.
3. Scope it small enough to finish and review in a single sitting. If it can't be, it's a parent. Pick the smallest valuable slice and leave the rest as a note.
4. Do it in the idiom of the surrounding code. Match its conventions, not your preferences.
5. Verify. Run the tests, build, and lint. For a user-facing change, also run the app and look at the rendered result, including its loading, empty, and error states. A green build never tells you a screen looks right or a flow feels right. Prove the change works with evidence, not "should work."
6. Commit on its own with a message saying what changed and why. One iteration, one reviewable commit.
7. Loop. Pick the next thing. Do not ask permission to continue. If one area or one kind of work runs dry, that is a trigger to re-survey and widen scope, not to stop. The whole repo is the field, never just the module you were last in. There is no commit quota and no natural finishing size: thirty small correct commits is a better run than eight, not a tired one. When the high-leverage work is gone, lower the leverage bar and rotate to a different kind of work in a different part of the repo rather than winding down. "Worth doing" means a senior reviewer would thank you, which is a far lower bar than "the single best thing left in the repo."