# /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:

```ini
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`.

---