Thirteen Days · Studio Playbook · July 2026

How bugs get fixed and ideas get built — /fixbug · /fixidea

Two commands run the whole repair shop — one for broken things, one for wished-for things — and the new founder-pickup layer handles whatever lands back on the founders' desk.

2 commands 7-step shared pipeline NEW founder pickup testers always get paid wrong command? auto-handoff 3 AIs can run it

I. Two commands, one repair shop

Testers post two kinds of things on libertyhillstudio.com: bugs (something in the game is broken) and ideas (something they wish the game did). Each has its own command, and either one runs the entire job — read the report, do the work, test it, ship it to production, close it out on the site, and make sure the tester gets their bounty.

🐛

/fixbug 53 — repair what's broken

A bug is a work order: the tester's own words are the spec. Claude diagnoses the real cause (not just the symptom), tries to disprove its own diagnosis first, then repairs it.

💡

/fixidea 12 — build what's wished for

An idea is a custom order: a new feature. Features change how the game plays, so on the site only a founder can green-light one — and before any code, Derek signs off on the design: what it touches, how it interacts, and proof it won't make the game easier. The game staying brutally hard is a law.

Type the wrong one? It hands itself off

The two commands are wired together. Run /fixbug on an idea and it says so in one line and continues as /fixidea — and vice versa. Nobody re-types anything; each item always gets its own correct process.

Derek only steps in a few times: to sign the design (ideas), to feel-test the change in the actual game, and to confirm the right item is being closed. Everything else runs on its own.

II. The shared seven-step pipeline

Both commands run the same seven steps — only the middle differs: a bug gets diagnosed and repaired, an idea gets designed and built.

1

Read the report — and the whole conversation from the studio site

Claude pulls the bug or idea straight from the website's database — who submitted it, their exact words, every message in its discussion thread (the tester's follow-ups, the robot fixer's past attempts, founder notes), plus the full state of the fix line. The report and its thread together are the spec — nothing gets diagnosed or designed before all of it is read.

2

A fresh workbench safe copy of the game

The fix happens on its own separate copy of the game's code (a "worktree"), so work-in-progress on other features can't get tangled up in it.

3

Do the work bugs: diagnose & repair · ideas: design & build

Bugs: Claude tries to disprove its own diagnosis before touching anything, so it never fixes the wrong thing. Ideas: the design goes to Derek first — the full mechanic thought through to its complete end, checked against the game's locked design decisions and its brutal difficulty. Either way, the game's full automated test harness has to pass.

4

Derek plays it the feel test

The moment it builds, Derek gets a live test link so he can feel the change in-game — while a deeper automated review runs in the background at the same time. Nobody waits on anybody. New features get staged on the test server before anything merges.

5

Ship it to production

The fix goes up as a pull request, passes the automated merge gate, and lands on main — which deploys the real game automatically.

6

Close it out on the site status → SHIPPED

The item's page flips to Shipped with a link to the exact change, the tester gets a friendly note — "it's fixed, feel free to re-test" for bugs, "it's in the game now, go try it" for ideas — and the studio activity log records it.

7

Wrap-up every link in hand

Derek gets all the links — the merged change, the bug's page, the test build — and the workbench gets cleaned up.

III. New — the founder-pickup layer JUST ADDED

Some bugs and ideas end up back on the founders' desk. The studio site's automatic fixer (the robot the testers know as Joey Blossom) pauses and asks a founder to make a call. Both commands now recognize those and handle the whole hand-back properly.

When does a bug land on the founders' desk?

📐

The scope grew

A tester asked for more than the original report covered, so the work paused for a founder to approve the bigger plan.

🚀

Waiting on the ship sign-off

A fix is done and tester-verified, but studio rule: nothing goes to production without a founder's signature.

🅿️

The robot parked it

Joey ran out of attempts, hit a blocker he couldn't clear, or the case got too big — "a human takes it from here."

What changes when the founder picks it up

The key idea: the founder's sign-off is the fix itself. Those approval gates exist so a founder personally vouches for anything that ships. If the founder is the one doing the fixing, the vouching has already happened — so /fixbug signs the paperwork instead of leaving it waiting on a desk forever.

Normal path
Robot fixer repairs the bugtester drives & verifies
Card lands in the founder's inbox"approve this to ship it"
Founder reviews & approves
Fix ships · bug marked Shipped
Founder pickup — new
Founder (via /fixbug or /fixidea) does the work directlyreusing the robot's work when useful
Approvals auto-signed by the founderthe sign-off is the fix
Fix ships · bug marked Shipped · founder comments on the bug: "I picked this one up and fixed it myself."
And the robot?

Joey's job on that bug is retired cleanly (marked merged, same as when he ships one himself), the founder's pending inbox cards are cleared, and the reporter still gets their "it's fixed — re-test it if you'd like" note. No dangling paperwork, no ghost tasks.

IV. The money never gets skipped

Testers earn real bounties — on bugs and ideas alike — and the founder doing the work never takes that away. This mirrors the studio's standing pay policy, exactly as it's written into the site.

50¢

Report bounty — for filing it

The reporter earns 50¢ the moment their bug or idea is approved. If that payment ever got missed along the way, founder pickup catches it and makes it whole.

$1

Fix bounty — for driving it

The trusted tester holding the fix keeps their $1 even when the founder does the code work. They drove the report, the replies, and the playtest — that's the paid part.

V. One playbook, three AIs

The whole process lives in one playbook file — and the studio's other AI assistants have been wired to run it too. Claude, Codex (OpenAI's coding agent), and Grok (xAI's) all follow the exact same steps, because their commands are just pointers to that one master file. Update the playbook once, and all three update instantly — no drift, no "which version is this AI following?"

🤖

Claude — full pipeline

Wrote the playbook and runs it end-to-end: read, fix or build, test, ship, close out on the site, pay the bounties.

⚙️

Codex — same playbook

Runs the identical steps: reads the report and thread, does the work, tests it, stages a build for Derek.

🚀

Grok — same playbook

Same again — first live runs already confirmed it follows the process correctly, including asking for the number instead of guessing.

The one extra rule for Codex & Grok

They do all the reading, fixing, and testing freely — but before the money and production steps (paying a bounty, marking a bug shipped, merging to the live game) they must show Derek the exact changes and get his typed go. Claude handles those end-to-end; the others hand Derek the pen for the signature.

VI. Guardrails