Use when an existing Forge game (runs/<slug>) should keep improving until it is ready ("keep improving until forge done is green", "the tycoon is scuffed, fix it", "make it good"), or when deciding whether a Forge game is finished.
Instal·la
npx skillscat add chocoliticekreem/mubithack/improving-games-until-done Instal·la des del registre de SkillsCat.
Improving a Forge game until done is READY
Overview
Read the shared game production guide from the mubithack checkout. Apply its priority bands, relevant genre/capability checks and verified-outcome rules. All AI decisions and generated fixes/checks must use Mubit-backed tasks.
done(slug) is the implemented readiness bar. Read its current parts rather than assuming this list is exhaustive. They include:
- checks: every executable check passes;
- features: every agent-added feature is verified;
- open: the last fix cycle left nothing high or medium;
- critic: the latest score is ≥ 8 (n/a for seeded games).
Choose the lever for the missing evidence. Repeating improve_game blindly can leave feature and coverage gaps.
The current bar also includes experience and interaction evidence. A green bar does not waive additional requirements for the user's target stage in the shared guide.
The loop
done(slug): write down the missing parts. That is your baseline.Per missing part:
Part Lever checks: "no check run yet" mubit-tester test_feature("<core loop>", game=slug, playtest=false)runs every saved check and records the results thatdonereadschecks: failing ids improve_game(slug), or fix that file. Thentest_feature(..., game=slug)againchecks: no checks exist use the Mubit-backed scenario planner: .venv/bin/forge checks <slug> --plan --run --studio <bound-studio>, then inspect coverage and resultsfeatures: not verified test_feature("<that feature>", game=slug)until PASSopen improve_game(slug, studio=...). It follows the job and ends with thedonebarcritic < 8 iterate(slug, iterations=2, studio=...), orfeature(slug, request)for what the critic says is missingAfter each lever,
done(slug)again. Compare it with your baseline.Stop when:
- READY;
- the
[ ]lines ofdone(part + detail) are word-for-word the same twice in a row (a
plateau): report what's stuck and the evidence; - you've done 6 rounds.
"Don't stop to ask" means don't ask. It doesn't mean loop forever.
If a round made things worse (a check went PASS → FAIL):
diff_since_last_run(mubit-tester),
thenbisect_versions(slug, check), thenrollback(slug, version).
Rules
- Pass
studio="<your local place>"toimprove_game,iterateandfeature. Never use aplaceIdwindow. - Run one job per Studio window at a time.
- Human-owned files get patches, not edits (
runs/<slug>/improve/patches/): show them, don't
claim they're applied.
Report format
<slug>: READY after <n> rounds | NOT READY (plateau | budget): <parts missing + details>
Baseline → now: checks a/b → c/d, open x → y, critic s → t
Rounds: 1) <lever> → <effect> 2) ...
Evidence: job ids, test ids, versions keptCommon mistakes
| Mistake | Fix |
|---|---|
Re-running improve_game without inspecting missing checks |
Use test_feature(game=slug) or the check workflow and inspect results; a fix cycle alone may leave coverage gaps |
| Claiming READY from a job log | Only done(slug) decides |
| No plateau rule | Stop after two identical done results and report |
Building without studio= |
It goes to the first connected window, maybe the shared place |