Skip to content
SlashClone
Made by@gameforge

Game design doc

@gameforge/game-design-doc

Write a one-page game design doc from a rough idea: the hook, core loop, controls, the one rule that makes it interesting, scope cut into must, nice, and later, and a first-playable plan. Short enough that you actually read it again, opinionated enough to stop scope creep.

SkillOtherv1.0.0 (latest)
Activity
New: be the first to try it

How this works

  1. It is a skill: written instructions Claude reads when your request matches what the skill is for. You do not call it by name; just ask for the task.
  2. While it works, it reads and changes files in the places it lists, nowhere else.
  3. Nothing runs until you choose to use it, and you can remove it any time.

SKILL.md

One-page game design doc

Most game design docs are 30 pages nobody reads. This one fits on a page and answers the only questions that matter before building: what does the player do every few seconds, why is that fun, and what is the smallest build that proves it.

Inputs

Ask in one message for whatever is missing. Offer a default for each so the user can say "go":

  1. The idea in a sentence or two.
  2. Platform and input: browser, phone, desktop, console; keyboard, touch, gamepad. Default: browser, keyboard plus touch.
  3. Time budget: a 48-hour jam, a month of weekends, or longer. This drives the scope cut.
  4. Who it is for: themselves, kids, friends, a jam theme, a store release.
  5. Reference games they like (optional). Use them to name the feel, not to copy them.

If docs/game-design.md exists, read it and update it in place instead of starting over. Keep the user's wording where it still holds.

Steps

  1. Find the hook. One sentence: "You are X, doing Y, but Z." Z is the twist. If there is no Z, propose two or three and let the user pick.
  2. Write the core loop as 3 to 5 verbs in order, measured in seconds (for example: aim, launch, bounce, collect, repeat). If one loop takes longer than about 30 seconds, say so.
  3. Name the one rule that creates interesting choices (risk versus reward, limited resource, timing). Every feature later must support it.
  4. Define win, lose, and progress: how a run ends, what carries over, what the score means.
  5. Cut scope for the stated time budget into three lists. Must is what the first playable needs. Be ruthless: for a 48-hour jam, Must has at most 5 items.
  6. Plan the first playable: the build that answers "is the core loop fun?" with placeholder art, in at most a quarter of the time budget. List the 3 questions a playtest of it should answer.
  7. List risks: the two things most likely to sink the project (usually scope and feel), each with a cheap test.
  8. Write docs/game-design.md in the format below. Keep it under about 80 lines.

Output

# <Title>: one-page design

**Hook:** You are a tiny lighthouse keeper keeping ships off the rocks, but your light also wakes the sea monster.
**Platform:** browser, keyboard and touch | **Budget:** 48-hour jam | **For:** jam theme "light and dark"

## Core loop (about 10 seconds)
Sweep the beam, spot a ship, guide it past the rocks, dim the light before the monster wakes, repeat.

## The rule that matters
Light saves ships and wakes the monster. Every second of light is a choice.

## Win, lose, progress
- Lose: three ships wrecked, or the monster reaches the lighthouse.
- Score: ships saved. Nights get longer and busier.

## Controls
| Action | Keyboard | Touch |
| ------ | -------- | ----- |

## Scope
- **Must:** ...
- **Nice:** ...
- **Later (not this version):** ...

## First playable (by hour 12)
Questions it answers: 1. ... 2. ... 3. ...

## Risks
| Risk | Cheap test |
| ---- | ---------- |

Guardrails

  • One page. If a section grows past a few lines, move detail to a separate doc and link it.
  • Never pad Must to look complete. A short Must list is the point.
  • Name feelings with verbs and numbers ("jump reaches 3 tiles, lands in under half a second"), not adjectives alone ("tight", "juicy").
  • Reference games describe a feel. Do not copy their names, characters, art, or text into the design.
  • Write only docs/game-design.md. Ask before replacing a doc the user wrote by hand.

README.md

Game design doc

Turns a rough game idea into a one-page design doc you will actually reread: the hook, the core loop, the one rule that makes it interesting, a scope cut that fits your time budget, and a plan for the first playable build.

Who it is for: game jammers, hobbyists, and students who have an idea and a deadline, and want to avoid spending the whole weekend on menus.

Example

You say:

I want to make a game about a lighthouse keeper for a 48-hour jam. Theme is "light and dark".

You get docs/game-design.md with:

  • Hook: You keep ships off the rocks with your light, but the light also wakes a sea monster.
  • Core loop (about 10 seconds): sweep the beam, spot a ship, guide it past the rocks, dim before the monster wakes.
  • The rule that matters: every second of light is a choice.
  • Scope: 5 Must items, a Nice list, and a Later list that keeps the jam safe.
  • First playable by hour 12, with the three questions its playtest should answer.
  • Risks with a cheap test for each.

What it can access

  • Reads docs/ and writes docs/game-design.md.
  • No scripts, no network, no env vars. Works in Claude Code, Codex, and Cursor.

Setup

None.

Files

  • README.md
  • SKILL.md
  • kit.json

Did it work?

0worked for them0did not work

Sign in to say whether it worked for you.

Nobody has said yet. Tried it? Tell the next person.