gm-gdd
Game Design Document phase for one tag. On the first ever run, runs the full Socratic interview, produces GDD.md, and derives ROADMAP.md (split into SemVer-tagged release tags).
Install / Use
npx skills add RandallLiuXin/GodotMaker --skill gm-gddInstalls into whichever agent you are using.
SKILL.md
Installable skill definition
Quality Score
Category
Content & MediaSupported Platforms
Our assessment of gm-gdd
gm-gdd scores 90/100 on our quality scale, 394th of 1,215 Content & Media skills we index (top 33%).
Its SKILL.md is 18 KB long, well organised into 26 sections with 3 code examples: a thorough specification that gives an agent plenty to work with.
It has 549 GitHub stars, a meaningful sign that others use it.
Maintenance, license and trust
- The repository was last updated 16 days ago, so gm-gdd is actively maintained.
- No license is declared. By default that means all rights are reserved: you can read it, but reusing or redistributing it is not clearly permitted. Ask the author before building on it commercially.
- Its trust signals score 88/100, with 1 caution from licensing, adoption, age or documentation. These come from repository metadata, not a code audit — read the skill file before letting an agent act on it.
gm-gdd compared with similar skills
All 4 of these similar skills score higher than gm-gdd; compare them before choosing.
| Skill | Score | Stars | Updated | Format |
|---|---|---|---|---|
| gm-gdd (this skill)by RandallLiuXin | 90 | 549 | 16d ago | SKILL.md |
| Agent-Reachby Panniantong | 100 | 89.8k | 18d ago | CLAUDE.md |
| siyuanby siyuan-note | 100 | 46.6k | today | MCP Server |
| algorithmic-artby anthropics | 100 | 177.9k | 11d ago | SKILL.md |
| pptxby anthropics | 100 | 177.9k | 11d ago | SKILL.md |
Frequently asked questions
- How do I install gm-gdd?
- Run
npx skills add RandallLiuXin/GodotMaker --skill gm-gdd. The install tabs above show the steps for each supported agent. - Which AI agents does gm-gdd work with?
- It is written for Universal, as a SKILL.md file. Other agents that read the same format can often use it too.
- Is gm-gdd safe to use?
- It declares no license and scores 88/100 on trust signals. Skills are instructions an agent will follow, so read the file before installing it and do not approve commands you do not understand.
- Is gm-gdd still maintained?
- The repository was last updated 16 days ago, so gm-gdd is actively maintained.
Skill content
View source on GitHubname: gm-gdd description: | Game Design Document phase for one tag. On the first ever run, runs the full Socratic interview, produces GDD.md, and derives ROADMAP.md (split into SemVer-tagged release tags). On every subsequent run, focuses the conversation on the current tag (the earliest entry in ROADMAP.md without a git tag), optionally updates GDD.md / ROADMAP.md, then generates the current tag's PLAN/STRUCTURE/SCENES/DESIGN/ASSETS at the project root. Explicit invocation only — use /gm-gdd. disable-model-invocation: true
GodotMaker GDD
$ARGUMENTS
You are running the design phase for one tag at a time. The pipeline is tag-iterative: each /gm-gdd invocation either bootstraps the whole project plus its first tag (initial mode), or focuses the next tag in ROADMAP.md (subsequent mode).
Session Setup
FIRST ACTION — before anything else: Write gdd to .godotmaker/current_role.
Resume Check
Read .godotmaker/stage.jsonl (treat as empty if missing) — each line is {"role": X, "ts": Y}.
- If
project.godotdoes not exist → STOP. Tell user to run/gm-scaffoldfirst. - If the last event has
role == "gdd"→ STOP. Tell the user:"GDD already completed for the current tag at {timestamp}. Recommended next: /gm-asset. If you need to redo this step or have other plans, just tell me."
- Otherwise → proceed (fresh project, OR new tag after the previous tag's
/gm-finalize).
Mode Detection
Detect the mode by inspecting on-disk state — there is no flag:
- Initial mode:
ROADMAP.mddoes NOT exist. (GDD.mdmay also be missing — if it is, this is a brand-new project.) - Subsequent mode:
ROADMAP.mdEXISTS. Determine the current tag as follows:- Read
ROADMAP.md, list tag entries in declared order. - Run
git tag --list 'v*'(capture stdout). - The current tag is the earliest tag in ROADMAP that is not in
git tag --list. - If every ROADMAP entry already has a git tag, STOP and inform the user the roadmap is exhausted — they must edit
ROADMAP.mdto add new entries before re-running/gm-gdd.
- Read
State the detected mode + (if subsequent) the current tag explicitly to the user as your first conversational message after Resume Check passes. They should never have to guess which tag they're working on.
Freeform Intake
Before invoking game-planner in initial mode, collect the user's rough idea in normal conversation, not AskUserQuestion.
- If
$ARGUMENTSalready contains a game idea, treat it as the freeform intake and do not ask again. - If
$ARGUMENTSis empty, ask the user for one open-ended paragraph: what they want to make, any references, mechanics, visual style, constraints, and anything they already decided. Make clear that rough notes are enough. - Pass this freeform intake verbatim into the
game-plannerbrief as "Initial User Concept". game-plannermust skip questions that the freeform intake already answers and use those details to choose smarter defaults.- Any "your call" / "you decide" language in the intake is scoped to the named topic or the current intake round unless the user explicitly grants broader delegation.
This intake is NOT a confirmation gate. Keep AskUserQuestion for explicit GDD and ROADMAP confirmations only.
Hard Rules
- You CANNOT write game code (.gd/.tscn/.tres). Code lives in workers in
/gm-build. - You CANNOT write to
assets/. Assets are produced in/gm-asset. - Use AskUserQuestion for confirmation. GDD must be explicitly confirmed by the user before generating ROADMAP / per-tag artifacts. ROADMAP must be explicitly confirmed before any artifact is written.
- MUST NOT skip the ROADMAP confirmation gate — see Sub-stages below. Initial mode WITHOUT a confirmed ROADMAP cannot proceed to artifact generation; subsequent mode with a roadmap edit WITHOUT re-confirmation cannot proceed either.
- Subsequent mode does NOT append tag-N sections to STRUCTURE/SCENES. It overwrites those root files with the current tag's scope. Prior tags' versions live in
docs/tags/<prev_tag>/. The cross-tag accumulating files areGDD.md,ROADMAP.md,DESIGN.md,ASSETS.md, andMEMORY.md. - GDD design changes that contradict shipped tags MUST be reflected as PLAN refactor tasks. When subsequent-mode interview reveals that a prior tag's behaviour now needs to change, the GDD update marks the old behaviour as
(superseded by ...)rather than deleting it, AND the new PLAN.md gains an explicit refactor / removal task in the Main Build section.
Sub-stages
1a — Interview & GDD update
Invoke the game-planner skill (.claude/skills/game-planner/SKILL.md).
Initial-mode brief MUST include the Freeform Intake as Initial User Concept; game-planner skips already-answered topics and uses the intake to choose smarter defaults.
-
Initial mode: game-planner runs the full Socratic interview → produces fresh
GDD.md. -
Subsequent mode: brief game-planner with:
- Current tag id (e.g.
v0.2.0) - The current ROADMAP.md entry for that tag (its bullet list)
- The full existing
GDD.mdcontent - The previous tag's
docs/tags/<prev>/PLAN.mdTag Mechanics list (so the conversation knows what already shipped)
Game-planner asks the user: "We're about to plan {Tag}. ROADMAP currently says {bullets}. Do you want to keep that scope, adjust it, or change the underlying GDD design?" — and runs a focused interview. If the user changes design intent, game-planner updates
GDD.mdin place: new sections appended, replaced sections marked(superseded by ...). Old GDD content is never silently deleted. - Current tag id (e.g.
Gate 1a:
- [ ]
GDD.mdexists and (if subsequent mode) reflects the user's latest intent - [ ] User has explicitly confirmed the GDD update via AskUserQuestion (or said "no changes needed")
1b — ROADMAP generation / adjustment
This sub-stage exists in BOTH modes but does different work.
Initial mode:
- Read
GDD.md(now confirmed). - Derive a tag list following the SemVer convention from
templates/ROADMAP.md:- First tag is always
v0.1.0and MUST deliver the first playable unit. - Every tag is a minimal playable unit: the player can experience a complete slice of gameplay with a completion, fail, or exit state.
- Every tag includes the player-facing information needed to understand and play that slice.
- Subsequent tags add one playable unit at a time.
- First tag is always
- Write a draft
ROADMAP.mdpopulated with this tag list. - MANDATORY gate: Use
AskUserQuestionto ask the user:"Here is the proposed roadmap. Is it OK to proceed with v0.1.0 as defined? You can also reorder, split, merge, or rewrite tags before we move on."
- If user requests changes, edit
ROADMAP.mdaccordingly and re-confirm. Do NOT proceed to sub-stage 1c until the user explicitly confirms the ROADMAP.
Subsequent mode:
- Read existing
ROADMAP.md. - If sub-stage 1a's interview revealed any roadmap-affecting decisions (user wants to reorder remaining tags, drop one, add one, or move scope around), edit
ROADMAP.mdaccordingly. Tags that already havegit tag <tag>are immutable — never modify their entries. - If you modified ROADMAP.md in step 2: use
AskUserQuestionto re-confirm the updated roadmap before continuing. If you did not modify it, no extra confirmation needed.
Gate 1b:
- [ ]
ROADMAP.mdexists, with at least the v0.1.0 entry (initial) or the current tag's entry intact (subsequent) - [ ] User has confirmed the roadmap (either fresh confirmation or "no changes" acknowledgement)
- [ ] Current tag id is established (initial: always
v0.1.0; subsequent: per Mode Detection)
1c — Per-tag decomposition
After GDD + ROADMAP are confirmed, decompose the tag in two phases. PLAN.md is the canonical source of task IDs, current-tag mechanic IDs, affected files, assets needed, and verify expectations. Do not generate STRUCTURE.md, SCENES.md, DESIGN.md, ASSETS.md, or TOC.md in parallel with PLAN.md; those artifacts must read the finalized PLAN.md instead of guessing task mappings.
Phase A — PLAN first. Launch one decomposer for plan-package only. It
owns only PLAN.md.
Agent({
subagent_type: "decomposer",
description: "Decompose current tag PLAN.md",
model: "{decomposer_model from .godotmaker/config.yaml, default: sonnet}",
prompt: "{shared brief below + Work Package: plan-package; Owned Files: PLAN.md}"
})
After it returns, the lead performs Gate 1c-A from disk and edits PLAN.md directly if needed. PLAN.md must be stable before Phase B starts:
- [ ]
PLAN.mdexists with**Tag:**header matching the current tag - [ ] Tag Mechanics section is populated with stable
[<Tag>-M<N>]ids - [ ] Inherited Mechanics section is populated for subsequent mode, or omitted for v0.1.0
- [ ] Playable Unit section is populated and references existing mechanic ids
- [ ] Playable Unit describes player experience, unit outcome, scenes involved, and per-mechanic player operation / effect / visible evidence
- [ ] PLAN covers the player-facing state, feedback, and presentation needed to play the current tag normally
- [ ] PLAN Runtime Asset Assignments binds required visible content to ASSETS.md rows, procedural output, UI text, or
not required this tagwith a deferral reason - [ ] Risk/Main tasks have stable task IDs and all Task Status rows start as
pending - [ ] Tasks list affected systems/scenes/assets clearly enough for downstream artifacts
Phase B — remaining artifacts in parallel. After Gate 1c-A passes, launch the remaining decomposer packages in the same message. Both packages MUST read the finalized PLAN.md and MUST NOT invent task IDs, mechanic IDs, affected files, or asset mappings that are absent from PLAN.md.
File ownership remains disjoint:
architecture-package: owns onlySTRUCTURE.mdandproject.godot.scene-asset-package: owns onlySCENES.md,DESIGN.md,ASSETS.md, andTOC.md.
All Phase B packages may read every input path, prior archive, and finalized PLAN.md, but each package may write only its owned files. After all reports return, the lead performs Gate 1c-B from disk and edits any mismatches directly.
Agent({
subagent_type: "decomposer",
description: "Decompose current tag STRUCTURE.md and project settings",
model: "{decomposer_model from .godotmaker/config.yaml, default: sonnet}",
prompt: "{shared brief below + Work Package: architecture-package; Owned Files: STRUCTURE.md, project.godot}"
})
Agent({
subagent_type: "decomposer",
description: "Decompose current tag SCENES.md, DESIGN.md, ASSETS.md, and TOC.md",
model: "{decomposer_model from .godotmaker/config.yaml, default: sonnet}",
prompt: "{shared brief below + Work Package: scene-asset-package; Owned Files: SCENES.md, DESIGN.md, ASSETS.md, TOC.md}"
})
Single-agent fallback. If dispatching decomposer subagents is unavailable,
launch one decomposer with no Work Package; it owns the full artifact set and
runs all steps serially. If Phase A succeeds but Phase B parallel dispatch is
unavailable, launch one decomposer for the remaining artifact set after PLAN.md
is finalized.
Shared brief:
## Task: Decompose current tag into per-tag artifacts
### Mode
{initial | subsequent}
### Current Tag
{vX.Y.Z}
### Project Root
{absolute path to project root}
### GDD Path
{absolute path to GDD.md}
### Roadmap Path
{absolute path to ROADMAP.md}
### Templates Dir
{absolute path to .claude/templates/}
### Project.godot Path
{absolute path to project.godot}
### Manifest Path
{absolute path to assets/manifest.json — include only if file exists}
### Prior Tag Archives (subsequent mode only — empty list if no prior tags)
- v0.1.0: {absolute path to docs/tags/v0.1.0/}
- ...
### Inherited Mechanics (subsequent mode only)
{copy the union of Tag Mechanics from every prior tag's docs/tags/<prev>/PLAN.md;
each line must
Truncated for display — read the full file on GitHub.
Related Skills
Agent-Reach
89.8kGive your AI agent eyes to see the entire internet. Read & search Twitter, Reddit, YouTube, GitHub, Bilibili, XiaoHongShu — one CLI, zero API fees.
siyuan
46.6kAn open-source, privacy-first, self-hosted knowledge workspace where humans and AI agents work together 开源、隐私优先、自托管的知识工作空间,让人与智能体在此协作
algorithmic-art
177.9kCreating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems.
pptx
177.9kUse this skill any time a .pptx or .potx file is involved in any way — as input, output, or both. This includes: creating slide decks, pitch decks, or presentations; reading, parsing, or extracting text from any .pptx or .potx file (even if the extracted content will be used elsewhere, like in an em…
Languages
Trust signals
From repository metadata: license, adoption, age and documentation. Not a code audit — see the Safety scan above for what the skill file itself contains.
