agentleFS
daveebbelaardaveebbelaar/bama/skills/ship/improve-loop/SKILL.md

improve-loop

Skill1.7k starsChanged 10 days agoMITView on GitHub

Autonomous loop that works through docs/STORIES.md one story at a time for a macOS app, building, snapshotting, comparing against reference screenshots, fixing, and committing, until a milestone is done. Use when the user says "keep going", "work through the backlog", "make it match the reference", or wants an unattended improvement loop.

5 other projects use a version of this, 2 of them edited.

Adopted by

Steady: 0 new projects took it in the last 4 weeks, none the 4 weeks before.thin data

Week of Sep 13: 0 new projectsWeek of Sep 20: 0 new projectsWeek of Sep 27: 0 new projectsWeek of Oct 4: 0 new projectsWeek of Oct 11: 0 new projectsWeek of Oct 18: 0 new projectsWeek of Oct 25: 0 new projectsWeek of Nov 1: 0 new projects
Sep 2026Oct 2026Nov 2026
New projects taking a version of this file each week, over the 8 weeks our latest run read: only 0 in all, so this is a hint, not a trend.

Most recently taken up by

Who's talking about daveebbelaar/bama

The biggest 5 of 42 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 42

Talked about on GitHub, YouTube and the web (42 times).

On GitHub · 20

15 more on GitHub

On YouTube · 13

8 more on YouTube

On the web · 9

4 more on the web

The file

We split this skill into the rules it gives an agent

9 rules. 0 are common, 2 are distinctive, and 7 are very specific to this project.

  • 0

    Common

    Most of the 5 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 7

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Stop after the milestone the user named, or after the current milestone if they named none.

    line 15
  2. Very specific:

    If the story adds a screen, an action, or words and has no UX: block yet, call the Skill tool with ux-design first.

    line 25
  3. Distinctive:

    Write two to five lines in your head or in the commit body: which files change, which model fields are new, which menu command and shortcut …

    line 28
  4. Very specific:

    Follow the swift-swiftui and mac-design skills, the story's UX: block, and design/DESIGN-SYSTEM.md if the app has one.

    line 35
  5. Very specific:

    Put new pages in the SidebarItem enum so snapshot mode visits them.

    line 38
  6. Very specific:

    Follow the build-and-verify skill.

    line 42
  7. Very specific:

    No reference screenshot (no app was cloned)?

    line 65
  8. Very specific:

    When the last story of a milestone is done, call the Skill tool with improve-architecture before you start the next milestone.

    line 100
  9. Very specific:

    When a story fixes a bug, add an entry to docs/FIXLOG.md: symptom, cause, fix, and a last line Rule: <what to always or never do>.

    line 105

“Common” is measured: kept by at least 6 in 10 of the 5 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Improve loop

One pass through the loop takes one story from todo to done:

pick story -> plan -> code -> ./build.sh -> snapshot -> compare -> fix -> commit -> update STORIES.md

Stop after the milestone the user named, or after the current milestone if they named none. Then report.

1. Pick

Open docs/STORIES.md. Take the first todo story in the current milestone whose dependencies are done. Set it to doing.

2. Plan

If the story adds a screen, an action, or words and has no UX: block yet, call the Skill tool with ux-design first.

Write two to five lines in your head or in the commit body: which files change, which model fields are new, which menu command and shortcut it adds, which snapshot page shows it. If the story needs a new SwiftData field, give it a default value so existing databases keep loading.

3. Code

Follow the swift-swiftui and mac-design skills, the story's UX: block, and design/DESIGN-SYSTEM.md if the app has one. System hooks follow os-integrations. Keep each view file under about 300 lines. Put new pages in the SidebarItem enum so snapshot mode visits them.

4. Build and snapshot

Follow the build-and-verify skill. If the story has logic, add a test or a self-test step (test-mac-app skill). Use seed data (APP_SEED=1) so pages show real content.

5. Compare

Open your snapshot and the story's reference screenshot side by side with the Read tool. Write down the differences that matter, in this order:

  1. Missing or wrong behavior from the acceptance criteria.
  2. Words and flow: names, surface, and states that differ from the UX: block or docs/GLOSSARY.md.
  3. Layout: wrong column, wrong order, missing element, and every FAIL from the grid checks.
  4. Hierarchy: what is biggest, boldest, first.
  5. Spacing and alignment.
  6. Color and details.

The goal is the same structure and behavior, built from Apple's own controls. It is not a pixel copy. When the reference uses a web-style custom control and macOS has a native one (a toolbar, a sidebar, a context menu, a date picker), use the native one.

No reference screenshot (no app was cloned)? Compare against the story's acceptance lines and the mac-design rules instead.

Snapshot only the pages a story touches (APP_SNAPSHOT_PAGES), and the full set at the end of each milestone.

Fix, rebuild, and compare again. Three rounds per story at most. If it still does not match, set the story to todo again with a note that says what is blocking, and move on.

6. Commit and record

git add -A
git commit -m "Complete tasks with Command-Return"

Set the story to done in docs/STORIES.md and commit that with the code. One story per commit, so any story can be reverted on its own. M1 may land as one commit when its stories share one skeleton (model, pages, list, persistence); from M2 on, one story per commit.

7. Report

At the end of the loop, report to the user:

  • Stories done, with one line each and the snapshot paths that show them.
  • Stories blocked, and why.
  • Anything the user should try by hand (shortcuts, drag and drop).
  • The next story in line.

Then ./build.sh --open so the user can try the new build.

Milestone check-in

When the last story of a milestone is done, call the Skill tool with improve-architecture before you start the next milestone. Unattended, do its top recommendation only if it is Strong, and leave the rest in the review file for the user.

When a story fixes a bug, add an entry to docs/FIXLOG.md: symptom, cause, fix, and a last line Rule: <what to always or never do>. The fix log outlives squashed history, and the check-in reads it.

Running it unattended

The loop works with no one watching, because every step checks itself: the build, the snapshots, the acceptance criteria. To let it run longer, start it with a clear limit ("finish M2, then stop"), make sure the tree is committed before you start, and never let it touch the user's real database. Each story is a separate commit, so the user can review the history in the morning and revert anything they do not like.

Done when every story in the milestone is done or named in the report as blocked with a reason, each done story has its own commit, and the user has the report.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.