gdd-writer
Skill2 starsChanged 6 months agoMITView on GitHub
Write or update a Game Design Document at `docs/design/<YYYY-MM-DD>-<slug>-gdd.md`. Use when adding mechanics, recording design decisions, or documenting scope. NOT for technical implementation — that lives in code and CLAUDE.md.
In this repository33 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- bootstrap-godot-projectSkill
- codebase-surveySkill
- create-autoloadSkill
- create-componentSkill
- create-resourceSkill
- create-sceneSkill
- create-state-machineSkill
- export-configSkill
- feature-planSkill
- feature-specSkill
- game-brainstormingSkill
- genre-pack-3d-actionSkill
- genre-pack-platformerSkill
- genre-pack-topdownSkill
- genre-pack-turnbasedSkill
- godot-patternsSkill
- gut-test-writerSkill
- networking-foundationSkill
- performance-auditSkill
- save-schema-migrationSkill
- setup-collision-layersSkill
- setup-git-godotSkill
- setup-input-mapSkill
- setup-localizationSkill
- setup-save-systemSkill
- sfx-generatorSkill
- shader-writerSkill
- subagent-dev-modeSkill
- ui-patterns-godotSkill
- update-docsSkill
- using-godot-superpowersSkill
- writing-game-planSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 22
If no GDD exists, create one with these sections.
- Distinctive: line 49
One section, one purpose: Don't mix mechanics into narrative.
- Very specific: line 112
After updating the GDD, check whether PROGRESS.md or CLAUDE.md need follow-up.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
GDD Writer
Maintains the Game Design Document at docs/design/<YYYY-MM-DD>-<slug>-gdd.md. Keeps design (what the game is and why) separate from implementation (how the code works).
Core rule: the GDD drives the code. If code diverges from the GDD, document the divergence in PROGRESS.md (or NOTES.md); never silently rewrite the GDD to match code.
File path convention
- Location:
docs/design/ - Filename:
<YYYY-MM-DD>-<slug>-gdd.md(date is the GDD's first-write date; slug is kebab-case of the working title). - One GDD per project. On major scope rewrites, write a NEW dated file rather than editing the old one — keep the trail. The plan file (
docs/plans/<YYYY-MM-DD>-<slug>-plan.md) references the GDD path.
Standard GDD sections
If no GDD exists, create one with these sections. Skip sections that don't apply to the genre.
| Section | Content | Update when |
| Concept (one line) | High-level pitch, tagline | Vision changes |
| Pillars | 3–5 design pillars driving every decision | Foundational shift |
| Tone & Identity | Aesthetic, mood, references | Art/audio direction shifts |
| Player Fantasy | What the player is and what they feel | Core fantasy refined |
| Genre & References | Genre tags, comparables ("X meets Y") | Repositioning |
| Core Loop | The 30-second moment-to-moment loop | Loop refined |
| Meta Loop | Run/session structure, progression between sessions | Meta added/changed |
| Mechanics | Each mechanic: rule, input, output | Mechanic added/changed |
| Systems | How mechanics combine (combat, economy, AI) | System designed |
| Controls | Input scheme per device | Mapping changes |
| Content | Levels, characters, items, enemies (lists) | Content added |
| Progression | XP, unlocks, difficulty curve | Progression tuned |
| Economy | Currencies, sources, sinks, faucets | Economy changed |
| Win/Lose Conditions | Per session, per run, per arena | Conditions change |
| Narrative | Story beats, characters, world | Story drafted |
| UI/UX | Diegetic vs non-diegetic, key screens | UI redesigned |
| Art Direction | Palette, style, references | Art bible refined |
| Audio Direction | Music style, SFX philosophy | Audio direction set |
| Scope | What's in V1, what's cut, stretch goals | Scope decisions |
| Open Questions | [HYPOTHESIS] items still being playtested | Hypothesis confirmed/discarded |
Writing rules
- One section, one purpose. Don't mix mechanics into narrative.
- No code, no class names, no file paths. That belongs in
CLAUDE.mdorPROGRESS.md. - Tables for structured data, bullets for lists, prose for fantasy/tone.
- Tag uncertain sections
[HYPOTHESIS]until validated through playtesting. - Numbers stay in the GDD for design intent (e.g. "player has 3 jumps"), exact tuning lives in
.tresresources or constants.
Adding a new mechanic
Template:
## [HYPOTHESIS] {Mechanic Name}
One- to three-sentence description of what the mechanic is and why it exists.
**How it works:**
- What the player does / sees
- How it integrates with existing mechanics
- What decisions / consequences it creates
**Why this mechanic:**
Tie to design pillars. If it doesn't reinforce a pillar, cut it or revise the pillar.
**Risks:**
- What could break? Balance, feel, complexity creep?
**Implementation order:**
Where this fits in the roadmap. Before/after the core loop is solid?Drop [HYPOTHESIS] once validated through playtesting.
Adding a content entry
Template (item, enemy, level — adapt fields):
**{Name}** — {Type}, {Tag/Element}, {key stats}
*"{Flavor text — one line, in the voice of the world}"*
{Role in gameplay in one sentence.}Example:
**Frostfang Pendant** — Accessory, Ice, +15 AP, +5% crit
*"Cold to the touch, even in summer."*
Mid-game DPS amulet for ice mages — pairs with Glacier Strike.Anti-patterns to avoid
| Anti-pattern | Why bad | Fix |
| Code snippets in the GDD | Mixes design with implementation, rots fast | Move to CLAUDE.md or commit message |
Class names like PlayerController | Implementation detail | Use design names ("the Hero") |
| Exact balance numbers without rationale | Hard to revisit | Always pair with intent |
| Walls of prose | Unscannable | Tables and bullets |
| No version / date | Can't tell what's current | Top-of-file "Last updated: YYYY-MM-DD" |
| Confirmed mechanics without playtest | False certainty | Keep [HYPOTHESIS] tag until validated |
Cross-references
After updating the GDD, check whether PROGRESS.md or CLAUDE.md need follow-up. The update-docs skill performs that cross-check.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

