メニュー
Structure learning paths for game development. Use when planning what to learn, choosing courses, tracking learning progress, or connecting learning to building. Prevents tutorial hell and ensures learning serves the game.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Declare what the system should be before writing code. Use when building new features, redesigning feature areas, or making significant changes that need a declaration of intent. Guides the declaration chain from findings through plans.
Wear the QA hat — think about quality the way a 15-year senior QA thinks. Use when building features, reviewing work, validating output, or when anything feels "done" but hasn't been proven to work. Prevents the gap between "it runs" and "it works."
Evidence-first research with mandatory citations and source evaluation. Use when gathering information for decisions, comparing approaches, investigating unknowns, or any task requiring verified evidence from multiple sources. Invoke at the START of research, not when writing up results.
Check and invoke available skills before starting work. Invoke at the start of any task to ensure relevant skills are loaded.
Effective Mermaid diagrams. Use when creating markdown documents with human audiences.
Guides effective documentation creation. Activates relevant guidance for north-star, gestalt, reference, research, design, plan, flow, findings, concepts, or process documents. Prevents cascading harm from wrong information.
| name | learning-planner |
| description | Structure learning paths for game development. Use when planning what to learn, choosing courses, tracking learning progress, or connecting learning to building. Prevents tutorial hell and ensures learning serves the game. |
| zones | {"knowledge":40,"process":30,"constraint":10,"wisdom":20} |
Tutorial completion is not learning. Building something you couldn't build before — that's learning.
Invariant Learn just enough to attempt the next thing. Build it. Hit a wall. Learn what the wall requires. Repeat.
Example Need player movement → learn GDScript basics (variables, functions, input handling) → build player movement → hit wall: sprite won't animate → learn AnimationPlayer → build animation → hit wall: physics feels wrong → learn RigidBody2D... //BOUNDARY: "Just enough" means the minimum to attempt, not the minimum to master. You'll learn the rest through building.
Depth
Invariant If you've completed 3 tutorials without building something original, you're in tutorial hell. Stop learning and start building.
Example Completed: GDScript basics, Godot scene tutorial, 2D platformer tutorial. Built from scratch: nothing. The cure: build a terrible, ugly version of the simplest thing you can imagine. A square that moves. A button that makes a sound. Anything. //BOUNDARY: Following a tutorial IS building — but only the first time. The second tutorial without original work is the warning sign.
Depth
Learn in the order your project needs, not the order a course suggests.
Programming Fundamentals
└── Engine Basics
└── Game-Specific Patterns
└── Polish & Optimization
Art Fundamentals (parallel track)
└── Tool Proficiency
└── Asset Pipeline
Programming fundamentals first: variables, functions, control flow, data structures. You can't learn engine scripting without these. boot.dev covers this well.
Engine basics second: scenes, nodes, input handling, basic physics. This is where you transition from "learning to code" to "learning to make games."
Game-specific patterns third: state machines, pathfinding, procedural generation, inventory systems. Learn these as you need them for your game, not ahead of time.
Art is a parallel track: Start when programming basics are solid enough to display what you create. No point learning pixel art if you can't render a sprite yet.
Each learning phase has:
| Element | Purpose |
|---|---|
| Goal | What you're learning to BUILD (not just learn) |
| Resources | boot.dev course + supplementary (YouTube, docs) |
| Practice project | Something original using what you learned |
| Done signal | How you know this phase is complete |
| Next trigger | What wall will tell you it's time for the next phase |
Phase: GDScript Fundamentals
Goal: Write a simple interactive scene from scratch (no tutorial)
Resources:
- boot.dev: [relevant GDScript/Python course]
- Godot docs: GDScript reference
- YouTube: "GDScript for beginners" (pick ONE, not five)
Practice: Build a number guessing game in Godot
Done signal: Can write a script that handles input, uses variables,
and has conditional logic — without copying from a tutorial
Next trigger: "I can write basic scripts but don't know how to
make things move on screen" → Engine Basics phase
When a decision-journal entry is recorded, it may create learning needs:
From sprint-manager: a learning ticket isn't done until you build something. This skill adds specificity:
A simple markdown file in the project:
# Learning Log
## Current Phase: Engine Basics
### Skills Unlocked
- [x] Write GDScript with variables, functions, conditionals
- [x] Handle keyboard input
- [ ] Create and switch between scenes
- [ ] Use AnimationPlayer for sprite animations
### Walls Hit (= next learning targets)
- Couldn't figure out scene transitions → need to learn SceneTree
- Sprite just sits there → need to learn AnimationPlayer
When the user says "I need to learn X":
When the user wants to "learn everything first":
boot-dev-companion skill — Specific boot.dev course guidancesprint-manager skill — Learning tickets with practice requirementsadhd-coach skill — Tutorial hell and perfectionism trapsgame-research skill — Research determines what needs learningLearn enough to build the next thing. Build it. Hit a wall. Repeat.