Godot GDD Skill | Explain Your Game Design Document

Explore Brutalist’s godot-gdd skill: turn a game design document into an explainer, using available game scenes and features to help visualize the design. Liam introduces the workflow and the optional Walker bookends.

TOOLS AND SOURCE Walker: https://github.com/nikbearbrown/walker Brutalist: https://github.com/nikbearbrown/brutalist.art Godot: https://godotengine.org/ Walker (Game AI): https://www.youtube.com/playlist?list=PLbeL9xXuLsLs

Liam is an AI narrator, in for Bear. This is a tutorial about the Brutalist skill, not a claim that a complete game was built in this episode. Independent educational production; not endorsed by Godot or Anthropic. Uploaded from the approved 3840 × 2160 landscape master.

Transcript

A lightly formatted transcript of the video, with timestamps so you can jump to any section on YouTube.

[0:00] An N Young, this is Liam in for Bear. There's a Brutalist skill called godot.gdd. Fellows look at that name and assume it writes the design document for them or reads their game code and extracts one. It does neither. So, I asked Claude to read the full skill and explain what actually happens when you point it at an existing godot project with a GDD already written. godot.gdd reads an existing game design document and builds the film explaining it section by section, status labeled, evidence grounded, not a generator. The document must already exist. That constraint is the entire design of the skill. The pipeline has four stages. Read the

[0:35] Full GDD including appendices and revision history. Map every top-level section to a beat or an explicit documented exclusion. Visualize each requirement beside real game evidence or a clearly labeled proposed diagram. Assemble via remotion scenes and compile pie same as every Brutalist film. The coverage contract is the strictest rule. Every substantive top-level section must appear in the film as a beat or as an exclusion with a written reason. Skipping a section without a note is a violation, not a judgment call. The skill calls this mapping, not summarizing, and the distinction matters. Every body beat carries one of four status labels: proposed, a design intent not yet built; implemented, the feature

[1:15] Exists in source; observed, a test or play through confirmed it; pending, a human decision the film cannot make. These labels are not style choices. They are the distinction the skill exists to enforce. The design's causal chain is the frame for every explained section. Player experience produces a design rule. That rule has a system owner. The owner produces visible feedback. Feedback maps to an acceptance test. Walk every GDD section through that chain. Any missing link is a gap and the film must name it, not paper over it. Before rendering an edit handoff, you run the checker art godot.gdd --check passing the real path and the GDD path. It verifies source

[1:52] Hash, section coverage, exact excerpts, evidence files, and beat status labels. What it cannot verify whether the explanation is true, whether the game is fun, or whether the design was approved. Those stay human. The walker modifier adds four explicit book ends to the standard walk through. First, a Claude composer opening shows the invocation reconstructed and labeled not a live session. Second, a hesitant writer beat states what is built versus proposed. Third, the design walk through proper, then verdict and handoff. Walker is not a separate skill. It is the same pipeline with Claude book ends at the front. Design tell is the phrase at the center of the skill. A proposal is not a

[2:28] Passing test. A feature can be implemented while its player experience hypothesis is untested. A test suite can pass while acceptance cases remain open. The skill enforces that distinction in every beat status label, not pessimism but precision. Collapsing design intent into implementation evidence is the failure the skill exists to prevent. Godot GDD does one thing precisely, builds a film that walks through an existing game design document section by section status labeled evidence on screen. What it does not do, write the GDD, change the game, approve the design, or certify it is worth playing. Those are yours. The film is the map. The territory stays human. Your turn. Here is a paste-ready prompt.

[3:07] Take a Godot game project you are working on or studying. Paste this into Claude. Walk me through the GDD for this project using the Godot GDD skill. Tell me which sections are implemented, which are still proposed, and flag any section where the acceptance test is missing or unmeasured. That last part, the missing acceptance test, is the gap most GDDs quietly hide.