Claude-Code-Game-Studios/.claude/skills/setup-engine/references/7.5-scaffold.md

/setup-engine — Section 7.5: Scaffold the Engine Project

Part of /setup-engine. SKILL.md names when to read this file; the settings it resolved and the rules under its later headings still apply here.

7.5 Scaffold the Engine Project

Without this step the framework produces source files no engine can open. /dev-story writes .gd/.cs/.cpp under the resolved code root, and the minimal path advertises "four steps to running code" — but nothing anywhere created a project for the engine to load. Verified by grep across every skill: no project.godot, no Unity project, no .uproject was ever written. The files were real and orphaned.

Godot — write project.godot if one is absent

Never overwrite an existing project.godot. If the file is already there, say so and skip to Section 8 — the developer has a project and its settings are theirs.

Show the proposed file, then ask: "May I create project.godot at the repo root?" On approval, write:

config_version=5

[application]

config/name="<project name>"
config/features=PackedStringArray("<major.minor>", "<renderer feature>")

[rendering]

renderer/rendering_method="<rendering method>"

Fill it from decisions already made — do not ask again:

Field	Source
config/name	the brief's working title, else the repo directory name
<major.minor>	engine.version from Section 3, major and minor only (4.7.2 → 4.7)
<renderer feature> / <rendering method>	the rendering value chosen in Section 5.5.1 — Compatibility → "GL Compatibility" / gl_compatibility; Forward+ → "Forward Plus" / forward_plus; Mobile → "Mobile" / mobile

Leave run/main_scene unset. There is no scene yet at engine-setup time. Add a comment saying /dev-story or the developer sets it once a scene exists; an empty project with no main scene opens fine in the editor.

Then verify, and report what the verification actually was. If the engine binary was found in Section 3, run its headless import (godot --headless --path . --import) and report the result — read the output for ERROR, because the import exits 0 even when something in the project fails to load. If the binary was not found, or its version differs from the pinned one, write project.godot NOT VERIFIED — <reason>. The config_version and feature strings are stable across Godot 4.x, but "stable in the versions I know" is not the same as "checked against the version you pinned", and only the run establishes the latter.

Unity and Unreal — instruct, do not fabricate

A Unity project and an .uproject are editor-generated and span many files, several of them binary or machine-specific. This repo cannot source their correct contents, and a hand-written scaffold would be the exact failure Section 7's sourcing rule forbids — something that looks finished and is quietly wrong.

Tell the user, in one short block, that CCGS does not create the project for these engines and they should create it first:

• Unity — create the project in Unity Hub at the repo root, choosing the template matching the 2D/3D answer from Section 2, then re-run /setup-engine.
• Unreal — create the project in the Epic launcher or via UnrealEditor, then re-run.

Report the outcome in the Section 12 summary either way — created, already present, or "not created, engine requires the editor" — so the user leaves this skill knowing whether a runnable project exists.

Deliberately not a project.yaml key. An engine.project_scaffolded flag would be written here and read by nothing, which is a dead setting — the same writer-without-reader defect the config gates exist to catch. The filesystem is the source of truth: any skill that needs to know globs for project.godot, *.uproject, or ProjectSettings/ProjectVersion.txt.

---