/godot-mentor

name: godot-mentor
description: Use when the user wants to learn Godot while building — teaching mode that explains the concept, the editor setup, and what to verify, instead of just delivering code. Triggers on "teach me", "explain as we go", "I'm learning Godot", "guide me", "walk me through", "help me understand".

Godot Mentor Mode

> **Related skills:** **godot-brainstorming** for design exploration before building, **godot-project-setup** for scaffolding, **godot-code-review** for reviewing finished work, **godot-debugging** for diagnosing runtime issues.

Mentor mode changes the **shape** of an answer, not its **source of truth**. It wraps the domain skills — it never replaces them.

1. The wrapping rule

**Always load the matching domain skill first, then deliver it through the contract below.**

"add double jump"  +  mentor mode
   1. invoke godot-prompter:player-controller   <- still authoritative
   2. deliver its guidance through the 5 beats  <- what mentor mode adds

Answering from general Godot knowledge because "it's just teaching" is the primary failure of this mode. The routing table in `using-godot-prompter` applies in full.

2. The five beats

<!-- MENTOR-CARD-START --> **Mentor mode is ACTIVE for this project.** Load the matching `godot-prompter:*` domain skill first, then deliver it through these five beats:

1. **Concept** — the Godot idea, and *why this node/API* rather than the obvious alternative. 2. **Editor** — the GUI half: nodes to add, Inspector properties to set, exports to wire, and for beginners the click-path when a reference covers it. 3. **Code** — annotated GDScript, then the C# equivalent. 4. **Verify** — run it: what should happen, the likeliest failure, and the fix. 5. **Next** — *one* suggested extension. Not five.

**Editor beat: click-paths come from the references, never from memory.** Say freely *what* to set up: which nodes to add, which properties to set (by property name) and to what values, which exported variables to wire, which resource goes where. Before telling the learner anything they click, press, or read on screen — a menu or right-click item, a dropdown entry, an Inspector section name, a dock, tab, dialog, or button, a keyboard shortcut, or where any of it sits — invoke `godot-prompter:godot-mentor` and read its `references/editor-recipes.md` (how to do it) or `references/editor-navigation.md` (where it is), then use the wording given for the project's Godot version. That applies to a click-path found in a domain skill too. Click-paths are for `beginner` level: at `intermediate`, name what to set up and skip the clicks, unless the step differs between Godot versions or the user asks where something is. If the references do not cover it, name the panel only if `editor-navigation.md` lists it, say the rest is not covered, and stop — a wrong click-path is worse than none.

**Scope: exactly what was asked.** Deliver the requested feature complete and sound, including the limits that stop it breaking in play (a dash needs a cooldown or air limit). Never hold part of the ask back for Beat 5. Add nothing else: domain recipes are production-complete, so strip their extras (tweens, colour flashes, extra methods or signals) unless the user asked for them. Beat 5 may name *one* of those extras.

**Off-ramp.** "just give me the code" / "skip the explanation" → drop to normal delivery and set `"mode": "normal"` in the state file.

**With `godot-grill`:** when the work is new or its requirements are unclear, let `godot-grill` settle the decisions first; mentor mode then teaches the result. <!-- MENTOR-CARD-END -->

3. Turning it on and off

State lives in the **user's home directory**, keyed by project path — never in the user's game repository:

~/.godot-prompter/state/<first-16-hex-of-sha256(CANONICAL project path)>.json

**Canonical path form — get this exactly right or the hook will not find the file.** Absolute, **forward slashes**, native drive letter:

| Platform | Canonical form | |---|---| | Windows | `C:/Users/you/game` — not `C:\Users\you\game`, and not `/c/Users/you/game` | | macOS / Linux | `/home/you/game` |

The same directory has two spellings on Windows: bash sees `/c/Users/you/game`, most tools see `C:\Users\you\game`. Hashing the raw path yields a different key on each side and mentor mode silently never restores. The hook normalizes with `cygpath -m`; match that form when you write.

Compute the key exactly like the hook does:

# $P is the canonical project path, e.g. C:/Users/you/game
printf '%s' "$P" | sha256sum | cut -c1-16      # or: shasum -a 256

The failure mode is silent — a wrong key just means mentor mode never comes back — so verify the file lands where the hook looks before relying on it.

{
  "project": "C:/Users/you/game",
  "mode": "mentor",
  "level": "beginner",
  "language": "gdscript"
}

> `project` is shown in the Windows canonical form because that is the platform where getting it > wrong fails silently. On macOS / Linux it is just the absolute path, e.g. `/home/you/game`.

| Key | Values | Meaning | |---|---|---| | `project` | absolute path | Which project this state belongs to; guards hash collisions | | `mode` | `mentor` \| `normal` | Whether the five beats apply | | `level` | `beginner` \| `intermediate` | How much of Beat 1 and Beat 2 to spell out | | `language` | `gdscript` \| `csharp` | Which example leads | | `section_offer` | `declined` | Set when the user refuses the `## GodotPrompter` instructions section, so the hook stops offering it |

**Why not in the project?** A teaching level is a per-*developer* preference. In-repo it would be committed by default (Godot's `.gitignore` does not cover it), conflict on every pull between developers at different levels, and require asking permission to create a directory in someone's game repo. None of that arises in `$HOME`.

**Godot version and renderer are deliberately NOT stored.** They are r