Godot Walkthrough Skill | Turn Gameplay into an Explainer

Walk through a Godot game and explain what is happening on screen with Brutalist’s godot-waikthrough skill. Liam introduces the gameplay-explainer 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] Anyong, this is Liam in for bear. There is a brutalist skill called god dot wakethrough. Most fellows read that name and assume it is a screen recorder. Drop a god dot project in get a gameplay video out. It is not. So I asked Claude to read the full skill and explain what actually happens when you point it at a game. The name reads like a screen recorder, but God wakethrough is the rift skill applied to gameplay. It plays the game through its actual input path, captures what the engine renders, and invokes Rift to narrate what happened on screen, the mechanism behind it, and the trade-offs the design made. Here is the

[0:32] Flow. You supply a path to a running God project. Claude identifies implemented features from source and a real run, distinguishing built from planned and broken. It drives the game through its normal input path, captures the rendered viewport, and invokes riff, which inspects captured frames and writes narration around what changed, why it matters, and the trade-off. The pipeline then assembles and renders a 4K walkthrough film. The skill has two modes. Standard mode opens on the game and its objective. Liam's brief introduction, then rift through the feature coverage. Walker mode adds four AI explainer bookends, a clawed composer beat with the design document prompt, a hesitant rider beat summarizing what was

[1:08] Built, the gameplay riff body, then verdict, and your turn. Walker mode is invoked by putting the word walker before the game path. Phase one is the inventory. The skill reads the game's design document and its source. then walks the project script, scenes, input map, and compares. Every feature gets a status, built, planned, or broken. A feature that appears in the GDD, but has no code yet stays planned. A feature with code that throws an error stays implemented with empty evidence, not relabeled, planned to pass the check. The inventory drives the play route. Phase two plays and captures. The skill drives the game through its normal input

[1:42] Path manually or with a deterministic input driver. Either way, it captures the real rendered viewport. The driver may observe position and state to choose inputs, but it cannot teleport the player, set completion flags, disable collisions, or call testonly shortcuts. Scripted input captures are labeled as such. They are not human play tests. The riff mechanic is the heart of the skill. After capturing, riff inspects each features captured frames and writes narration around three things. What changed on screen? Why that mechanism works that way and the useful trade-off the design made. Source code facts and untested judgments are identified as such. The human judges feel and fun.

[2:17] Riff plays records, explains, and checks. In Walker mode, the film gains four structured bookends in this exact order. First, a clawed composer beat where the prompt begins, "Please use Walker to convert my game design document about dot dot dot," and describes the game's actual idea. Second, a hesitant writer beat summarizing what was built, not the GDD promises, the actual delivered slice. Third, the gameplay riff body. Fourth, verdict, then your turn, then the regular outro. The design tell is explicit in the skill file and worth reading verbatim. The skill cannot secretly fix the game. No teleporting the player past a blocker. No disabling collisions to claim a past level. No

[2:53] Calling testonly shortcuts to manufacture a completion receipt. A driver may observe position and state to choose inputs. It may not change the game. The honest path if it cannot run report the exact blocker. The falsifiability gate is built into the design. If the game cannot run, the skill does not fake the result. It reports the exact blocker. No substitute fixture, no screenshot slideshow, no imagined success. This real runs that limitation. Honestly, there's no God project in this isolated build. So, we demonstrated the mechanism with labeled teaching illustrations. A full god wakethrough build needs a real running game. Verdict: What the skill gets right, it makes the evidence contract

[3:30] Explicit from the first phase. Identify from source plus a real run, not the GDD. Capture the real viewport, not a substitute fixture. Riff on what is visible, not what the code says should happen. The limitation is structural. This skill requires a real running game as input. Give it a shallow game and the walkthrough film will be shallow too. Your turn. Here is the paste ready prompt. Read skills/make/god.wickthrough/skill.mmd in full. I have a god.4 project at path. Produce a phase one feature inventory. List every implemented feature from source and mark each as built planned or broken. Then write coverage.json for my game. Replace path with any god.4

[4:06] Project folder you have when claude comes back. Verify the inventory against what you know the game actually does. If a feature is missing, ask it to read that specific script and trace the input path. The inventory quality is the quality of the walkthrough film. Lay them in for bear.