What's inside

One SKILL.md (the playbook) + one starter template. A preview:

Weekend Prototype Sprint

When to use

• You have a game idea and one weekend — and no game-dev experience (or no time).
• You want to test whether an idea is fun before committing months to it.
• You're evaluating what an AI coding agent can actually do on a real creative task, with your own hands.
• You need a playable demo for a pitch, a game jam, or a team brainstorm on Monday.

Workflow

1. Scope to "bad but improvable" (input: your idea → output: sprint brief)
   Write the brief in one paragraph: genre, the single core loop (one verb — "dodge," "stack," "aim"), win/lose condition, and what you will deliberately NOT build (no menus beyond start/restart, no save system, no audio beyond bleeps, no art beyond colored shapes). If the fun doesn't survive colored shapes, art won't save it. Cap the scope at what one person can prompt in ~3 hours of active work across two days.
2. Pick the stack the agent knows (input: sprint brief → output: stack choice)
   Choose the engine/framework your agent has the most training data on (a mainstream engine or a plain web canvas game). Decide the agent interface up front: agent writes code in your editor, or agent drives the engine through an MCP-style connector. Set up the project, the build/run command, and screen capture — the agent needs to see the game to iterate on it.
3. Write the build prompt (input: brief + stack → output: prompt pack)
   Give the agent: the one-paragraph brief, the stack and version, the exact run command, the "done" criteria (game launches, core loop playable for 60 seconds, restart works), and the explicit out-of-scope list. Add one line that prevents the classic failure: "Build the smallest playable version first; do not add features I didn't ask for."
4. Run the agent loop (input: prompt pack → output: playable build + iteration log)
   Let the agent build, run, screenshot, and fix — you review, don't micromanage. Your job per cycle: (a) confirm it runs, (b) play 60 seconds, (c) give exactly one piece of feedback ("the jump feels floaty; make gravity stronger"). Keep an iteration log: timestamp, what you asked, what changed, what broke. Stop adding features at 80% of your time budget — the last 20% is playtesting.
5. Playtest like a stranger (input: playable build → output: fun verdict)
   Hand it to someone who hasn't seen the process. Watch silently for 5 minutes and note: do they understand the goal without explanation? Do they laugh, lean in, or ask "is that it?" Score 1–5 on: clarity of goal, feel of the core loop, and "one more try" pull. A 3+ on pull with a 2 on clarity means the idea works and the tutorial doesn't — that's a fixable, fundable result.
6. Decide: kill, shelve, or continue (input: fun verdict → output: decision memo)
   Write the memo: what the prototype proved (the loop is fun / isn't), the three biggest unknowns a real build would face (art pipeline, netcode, content volume — the things agents don't solve), and the honest next step. "Bad but improvable" is a success if it answered the fun question; it's not a success if you spent the weekend adding features to avoid the answer.

Template preview

Weekend Prototype Sprint Worksheet

One weekend. One core loop. "Bad but improvable" is the target.

1. Sprint brief (one paragraph)

Genre, the single core-loop verb, win/lose condition:

Explicitly OUT of scope (menus, saves, audio, art — list them):

Active-work budget: ~3 hours across two days. Hard stop time:

2. Stack choice

• Engine / framework (pick what your agent knows best):
• Agent interface (editor agent? MCP-style connector?):
• Run command:
• How the agent sees the game (screen capture setup):

3. Prompt pack (what you actually send the agent)

• The brief:
• Stack + version:
• Run command:
• Done criteria (launches / 60s playable / restart works):

Buy the full skill pack — $4.99 Pro — all 511 skills