AgentSkillsCN

godot-distiller

需求提炼器——可将复杂的游戏设计文档(GDD、PRD、功能列表)转化为一份范围明确、单次会话即可完成的构建计划,让生成器真正能够落地执行。 通过识别核心游戏循环并剔除一切无关内容,有效防止需求范围无限制膨胀。 触发条件: “提炼”、“界定范围”、“制定会话计划”,或当生成器检测到复杂的多文档输入时触发。

SKILL.md
--- frontmatter
name: godot-distiller
description: |
  Requirements Distiller — takes complex game design documents (GDDs, PRDs, feature lists)
  and produces a scoped, single-session build plan that the builder can actually deliver.
  Prevents scope explosion by identifying the core gameplay loop and stripping everything else.
  Triggers on: "distill", "scope", "session plan", or when the builder detects complex multi-doc input.

Requirements Distiller

Purpose

Complex game designs (heist planners, RPGs, multi-screen games) have dozens of features. The builder's biggest failure mode is trying to build ALL of them in one session — delivering nothing well. The distiller prevents this by producing a focused, single-session build plan that contains ONLY what can realistically be built and tested in one Claude session.

When This Skill Activates

  • User provides a folder with multiple design documents
  • User provides a GDD/PRD with more than 3 screens or 15+ features
  • The builder detects the scope exceeds a single-session capacity (~12-15 scripts)
  • User explicitly asks to "distill", "scope", or "plan sessions"

The Distillation Process

Step 1: Read Everything

Read ALL documents in the user's folder:

code
Glob: <docs-folder>/**/*.md, **/*.txt, **/*.json, **/*.yaml
Also: **/*.png, **/*.jpg (note as art assets)

For each document, extract:

  • Features: Every distinct feature mentioned (list them ALL)
  • Screens/Scenes: Every UI screen or game scene described
  • Entities: Every game entity (player types, enemies, items, buildings, etc.)
  • Systems: Every backend system (scoring, progression, energy, currency, PvP, etc.)
  • Assets: Every art asset mentioned or found in the folder

Step 2: Identify the Core Loop

The core gameplay loop is the ONE thing that makes the game fun. Strip away everything that is not essential to experiencing this loop.

Questions to ask:

  1. What does the player DO most of the time? (This is the core mechanic)
  2. What is the minimum set of entities needed for that mechanic to work?
  3. What is the simplest win/lose condition?
  4. What is ONE screen where all of this happens?

Examples:

Game ConceptCore LoopNOT Core
Heist plannerTap building → solve puzzle → get lootShop, daily rewards, PvP, guilds, leaderboards
Match-3 RPGMatch tiles → damage enemies → level upGacha, social features, events, territories
Tower defensePlace towers → waves attack → upgradeStory mode, multiplayer, achievements
City builderPlace buildings → earn resources → expandTrading, diplomacy, war, quests

Step 3: Scope Into Sessions

Each session can realistically produce:

  • Max 12-15 scripts (more = cascading errors)
  • 1-2 screens (more = incomplete UI)
  • 3-5 entity types (more = untested interactions)
  • 1 core system (more = integration nightmares)

Session Scoping Rules

Session 1: Core Loop (MANDATORY FIRST)

  • The ONE screen where gameplay happens
  • Player entity + primary action
  • 1-2 challenge entities (enemies, obstacles, puzzle elements)
  • Basic win/lose condition
  • Minimal HUD (score or status only)
  • Max 8 scripts, zero optional features

Session 2: Depth

  • Second screen (menu OR results — not both)
  • 1-2 more entity types
  • Basic progression (difficulty increase, scoring)
  • Max 5 new scripts

Session 3: Flow

  • Remaining screens (menu, game over, pause)
  • Screen transitions
  • Full game flow: menu → play → end → retry
  • Max 5 new scripts

Session 4: Polish

  • Visual effects (particles, shaders, screen shake)
  • Audio (procedural or loaded)
  • UI styling (no default Godot theme)
  • Game feel tuning
  • Modifies existing scripts, few new ones

Session 5+: Features

  • Shop, progression systems, daily rewards
  • Additional game modes
  • Social features, leaderboards
  • Each session adds ONE system
  • Max 5 new scripts per session

Step 4: Map Assets

For each session, identify which assets are needed:

  1. Scan the docs folder for existing assets: *.png, *.jpg, *.svg
  2. Map each asset to a game entity: bank.png → bank building, player.png → player character
  3. List which assets Session 1 needs (only those entities in scope)
  4. Flag assets without entities: "Found hacker.png but hacker character is not in Session 1"
  5. Flag entities without assets: "Enemy guard is in Session 1 but no guard sprite found — will use procedural"

Step 5: Write SESSION_PLAN.md

Output the plan to docs/SESSION_PLAN.md in the project directory.

markdown
# Session Plan: [Game Name]

## Source Documents
- [filename]: [brief description of contents]
- [filename]: [brief description of contents]

## Core Gameplay Loop
[One paragraph describing what the player does and why it's fun]

## Session 1: [Title] (THIS SESSION)

### Features to Build
1. [Feature]: [brief spec — mechanics, numbers, behavior]
2. [Feature]: [brief spec]
3. [Feature]: [brief spec]

### NOT Building This Session
- [Feature from docs]: deferred to Session [N]
- [Feature from docs]: deferred to Session [N]
- [Feature from docs]: deferred to Session [N]
(List EVERY feature from the docs that is being cut)

### File Manifest
| File | Purpose | Lines (est.) |
|------|---------|-------------|
| scripts/main.gd | Main scene controller, spawn system | ~120 |
| scripts/player.gd | Player movement and interaction | ~80 |
| ... | ... | ... |
**Total: [N] scripts (max 12)**

### Assets
| Asset | Source | Entity |
|-------|--------|--------|
| bank.png | User-provided (docs/assets/) | Bank building |
| player.png | User-provided (docs/assets/) | Player character |
| guard.png | Generate procedural | Guard enemy |
**Copy to**: `res://assets/sprites/`

### Technical Decisions
- **Scene structure**: [how the main scene is organized]
- **Collision layers**: [which layers for what]
- **Autoloads**: [singleton managers needed]
- **Input**: [input actions needed]

### Success Criteria
When Session 1 is complete, the player can:
1. [Concrete testable action]
2. [Concrete testable action]
3. [Concrete testable action]

---

## Session 2: [Title] (NEXT)
### Features
- [Feature 1]
- [Feature 2]
### New Files: ~[N] scripts

## Session 3: [Title]
### Features
- [Feature 1]
- [Feature 2]
### New Files: ~[N] scripts

## Session 4: Polish
### Focus
- Visual effects, audio, UI styling, game feel

## Session 5+: [Optional Features]
- [Feature]: [which session]
- [Feature]: [which session]

Step 6: Present to User

After writing SESSION_PLAN.md, present a summary:

code
Distilled [N] documents into a [M]-session build plan.

**Session 1** (this session): [title]
- [N] scripts, [M] assets
- Core: [one-line description of what the player can do]

**Deferred**: [list of cut features]

Review docs/SESSION_PLAN.md. When ready, I'll start building Session 1.

Wait for user approval before the builder starts.

Integration with Builder/Director

When the builder detects complex docs and invokes the distiller:

  1. Distiller runs Steps 1-6, writes SESSION_PLAN.md
  2. User approves the plan
  3. Builder routes to Director with SESSION_PLAN.md as the source (not the raw docs)
  4. Director reads SESSION_PLAN.md instead of the full design docs
  5. Director generates PRD from the session plan (scoped, not the full game)
  6. Director executes Phases 1-6 for Session 1 only

For subsequent sessions:

  1. User starts a new Claude session
  2. Builder checks godot_get_build_state() — finds Session 1 complete
  3. Builder reads SESSION_PLAN.md — identifies Session 2 scope
  4. Director picks up from Session 2, adding to existing codebase
  5. Repeat until all sessions complete

Scoping Heuristics

Feature Classification

CategorySessionPriority
Core mechanic (what player does)1MUST
Primary challenge (what opposes player)1MUST
Win/lose condition1MUST
Basic HUD (score/status)1MUST
Additional entity types2HIGH
Menu screen2-3HIGH
Game over / results screen2-3HIGH
Difficulty progression2HIGH
Pause menu3MEDIUM
Screen transitions3MEDIUM
Visual polish (shaders, particles)4MEDIUM
Audio (SFX, music)4MEDIUM
Shop / store5+LOW
Daily rewards5+LOW
Leaderboards5+LOW
Social features5+LOW
Multiplayer / PvP5+LOW
Guilds / clans5+LOW
Achievements5+LOW
Analytics / telemetry5+LOW
IAP / monetization5+LOW

Red Flags (scope is too big for one session)

  • More than 3 distinct screens described → multi-session
  • More than 5 entity types → multi-session
  • Any mention of: PvP, multiplayer, guilds, social → defer to Session 5+
  • Any mention of: shop, IAP, daily rewards → defer to Session 5+
  • Any mention of: progression systems, skill trees, crafting → defer to Session 3+
  • File manifest exceeds 12 scripts → split into sessions
  • Design doc is more than 5 pages → likely needs distillation

When NOT to Distill

  • User provides a short prompt (1-3 sentences) → builder handles directly
  • User explicitly says "simple" or "basic" → no distillation needed
  • Game concept has one screen and one mechanic → no distillation needed
  • User provides a pre-scoped session plan → skip distillation

Example: Heist Planner Distillation

Input: 4 design docs describing city map, puzzle mechanic, results screen, shop, daily rewards, PvP raids, guilds, 18 art assets.

Session 1: City Map + Building Tap

  • City map screen with tappable buildings
  • 5-6 building types using provided PNG assets
  • Building info panel on tap
  • Basic player stats (cash, level)
  • 8 scripts, 8 assets from docs folder

Session 2: Puzzle Mechanic

  • Laser grid puzzle scene
  • Tile rotation mechanic
  • Timer and scoring
  • Transition from building tap → puzzle
  • 5 new scripts

Session 3: Results + Flow

  • Results screen with loot display
  • Main menu
  • Full flow: menu → city → tap → puzzle → results → city
  • 5 new scripts

Session 4: Polish

  • Cyberpunk visual effects
  • Audio
  • UI styling
  • Animations and transitions

Session 5+: Meta Features

  • Shop (Session 5)
  • Daily rewards (Session 6)
  • PvP raids (Session 7)