Game docs

Keep a game's design written down in as few words as will stay true. The GDD is one page that says what the game is and maps its features; each feature's detail lives in its own short note; and every number in the docs matches the code. Docs nobody keeps current are worse than none, so write less, edit in place, and sync after every change.

When to use

Run only when the user asked for game design docs, or when the project already has a GDD and a feature is being designed, changed, built or cut. A request to build a game or a feature is not a request for docs: let the engine and genre skills build it (through $router) and offer docs in one line at the end. Level layouts go to $level-design; READMEs, API docs and code comments are not this skill's job.

Workflow

1. Look before writing.
   • Find the existing docs: GDD.md, *design*, *spec*, docs/, design/, a wiki folder, specs/ (GitHub spec-kit) or .kiro/specs/ (Kiro). Keep their folder, file names, language and format.
   • Read the conversation (a planning chat is your main source) and, when code exists, the repo and git diff/git log. Never ask what the repo or the chat already answers.
   • Sort the project into one of three cases. This decides everything below:
     • No GDD. Only a request for a GDD starts one.
     • A GDD in this layout (a feature index plus features/<slug>/design.md). Use the modes as written.
     • A GDD in any other form (one long file, a wiki page, spec-tool folders). Edit it in place, in its own format. Make the smallest edit, in the user's style. Don't add an index, folders or headers to it, and don't suggest restructuring unless the user asks (mode E).
2. Pick the mode and read its section in references/workflow-modes.md: