agentleFS
Simone-TarantinoSimone-Tarantino/godot-superpowers/skills/gdd-writer/SKILL.md

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.

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
  1. Distinctive:

    If no GDD exists, create one with these sections.

    line 22
  2. Distinctive:

    One section, one purpose: Don't mix mechanics into narrative.

    line 49
  3. Very specific:

    After updating the GDD, check whether PROGRESS.md or CLAUDE.md need follow-up.

    line 112

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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.

SectionContentUpdate when
Concept (one line)High-level pitch, taglineVision changes
Pillars3–5 design pillars driving every decisionFoundational shift
Tone & IdentityAesthetic, mood, referencesArt/audio direction shifts
Player FantasyWhat the player is and what they feelCore fantasy refined
Genre & ReferencesGenre tags, comparables ("X meets Y")Repositioning
Core LoopThe 30-second moment-to-moment loopLoop refined
Meta LoopRun/session structure, progression between sessionsMeta added/changed
MechanicsEach mechanic: rule, input, outputMechanic added/changed
SystemsHow mechanics combine (combat, economy, AI)System designed
ControlsInput scheme per deviceMapping changes
ContentLevels, characters, items, enemies (lists)Content added
ProgressionXP, unlocks, difficulty curveProgression tuned
EconomyCurrencies, sources, sinks, faucetsEconomy changed
Win/Lose ConditionsPer session, per run, per arenaConditions change
NarrativeStory beats, characters, worldStory drafted
UI/UXDiegetic vs non-diegetic, key screensUI redesigned
Art DirectionPalette, style, referencesArt bible refined
Audio DirectionMusic style, SFX philosophyAudio direction set
ScopeWhat's in V1, what's cut, stretch goalsScope decisions
Open Questions[HYPOTHESIS] items still being playtestedHypothesis 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.md or PROGRESS.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 .tres resources 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-patternWhy badFix
Code snippets in the GDDMixes design with implementation, rots fastMove to CLAUDE.md or commit message
Class names like PlayerControllerImplementation detailUse design names ("the Hero")
Exact balance numbers without rationaleHard to revisitAlways pair with intent
Walls of proseUnscannableTables and bullets
No version / dateCan't tell what's currentTop-of-file "Last updated: YYYY-MM-DD"
Confirmed mechanics without playtestFalse certaintyKeep [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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.