Godot Narrative Workflow

Overview

Use this skill for Godot narrative-game production work that sits between design and implementation. It is meant for repeatable project workflows: orienting a Godot narrative project, reconciling docs with runtime state, migrating a proven workflow into a new project, splitting work into modules, implementing low-art playable slices, and verifying changes with fast contracts before manual playtests.

If the task is only story/prototype planning without Godot production work, use a narrative prototype skill instead. If the task is a generic UI/event change with no narrative-doc layer, combine this skill with the existing game UI or event workflow skills.

Read references/godot-narrative-workflow.md for the concrete checklist when the task touches docs, JSON data, manifests, smoke tests, module indexes, or project workflow migration.

Workflow

1. Identify the project stage.
   • Pre-engine: no project.godot; do not claim runtime verification.
   • Graybox/runtime: Godot project exists; verify scene/script/data load paths.
   • Polish/release hardening: separate automated proof from real-window playtest needs.
2. Locate the authority chain.
   • Read AGENTS.md, CLAUDE.md, docs/README.md, source docs, development docs, devlog, and playtest log only as needed.
   • Treat docs/source/ as facts/specs and docs/development/ as execution notes when that split exists.
   • Before saying a feature is missing, check live JSON, scripts, manifests, tests, and devlog.
3. Keep content data-driven.
   • Prefer one runtime shell plus JSON/config tables for fragments, chapters, outcomes, manifests, and reward states.
   • Keep wrappers thin when a shared runtime exists.
   • Preserve stable IDs and runtime keys unless the project has a migration plan.
4. Advance low-art work deliberately.
   • Separate no-art playable progress from art-dependent polish.
   • Good low-art work includes graybox chapters, save/restore, reward locks, progress UI, hint/feedback text, settings, debug unlocks, static contracts, and smoke tests.
   • Do not block all progress on final art when data and runtime contracts can move forward.
5. Verify before completion.
   • Use static contracts for JSON, manifests, required IDs, node paths, text routing, and unlock conditions.
   • Use official Godot console headless/import or project-specific smoke scripts when the project exists.
   • Write logs under a project work/ folder when user://logs is unreliable.
   • Record unresolved manual QA needs separately from automated checks.

Output Expectations

End with:

• evidence inspected: docs, data, scripts, manifests, tests, logs
• changed files or proposed files
• verification actually run, with scope clearly labeled
• manual playtest steps or remaining real-window QA gaps
• boundaries: what was intentionally not touched