Before you send it to the builder

The validator (the checking tool) checks what it can prove from the files. A final read by a person checks what only a designer can judge: whether the package describes one clear game. Use this list before you give the design to a builder.

The package passes validation#

Run npx opengdd validate <package-dir> and fix every error.
Read each warning. Fix the accidental ones and confirm the intended ones.
Confirm the five required files are there: manifest.json, tuning.json, 01-overview.md, 02-mechanics.md and 05-build-plan.md. Every numbered chapter should have its own purpose.

The chapters describe one game#

Read the fantasy block. Then read every chapter quickly and compare it with the block. The rules, the mood and the presentation should describe the same experience.
Check that each rule is stated once, and briefly. Being thorough means deciding every rule, not writing more words. Check that shared numbers are named by their tuning key instead of copied into prose. Keep an item's own numbers in its collection record, and test inputs with their tests.
Find anything a player would notice that changes how the game plays, not just how it looks. Decide each one by its value or by its target: a rule, a test, or a sentence saying what it must achieve. A Personalization question can decide it too. You can leave a choice to the builder. When the choice changes how the game plays, write the target it must reach and its limits. When it does not, write its limits.
Check that every open number, one you have not decided yet, has a target next to its citation. Check also that you have not named numbers whose values no player could tell apart.

Optional files are connected#

Make sure every collection is cited in prose, linked from another record, or named by a rule in tuning.json. Add a _collection.json schema when the records share required fields or link fields.
For each link field, confirm to names the right collection. If links must not form a loop, or must exist in both directions, write that on the field (loops: false, mirrored_by).
For art direction and palettes, keep the intent that people judge separate from the measured promises. Connect every measured promise to an acceptance test.
For Personalization, give every question a meaningful default. Check that every possible answer still gives a game you would release.
For a contract, read its questions, answer every one that applies, and run npx opengdd render-contract-tests <package-dir> after an answer changes. Review the tests it shows; do not paste them into the build plan.

The build plan is complete#

Read the build stages in 05-build-plan.md in order. Each stage must say what to build. A stage can also name the chapters that define the work, and say how to recognize that it is done. Both are optional. A common order is core loop, content, tuning, presentation, then polish. The format requires at least one stage, but the validator cannot check the stages. You check them by hand.
Read every acceptance test. Together they should cover the promises that matter most, without telling the builder which code or engine to use. Tests are optional, but a build of a package without tests is reported as not verified.

If this read raises a question about the format, open the OpenGDD specification. If it shows a design decision you have not made yet, make it and update the package.

After the handoff#

A first build of your own, or one made for you, shows which rules the package did not state. When a builder finds a place where the package is unclear, they can write an ambiguity report: what they found, what the package left open, and which version of the package they used. A builder can send it to you as an issue against the package. Settle the question, update the package, and give the builder the new version.