Before you hand it over

The validator (the checking tool) checks what it can prove from the files. A last human read checks the part only a designer can see: whether the package says one clear thing. Use this list before you hand the design to a builder.

The package opens cleanly#

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 design reads as one game#

Read the fantasy block, then skim every chapter against it. The rules, the mood and the presentation should describe the same experience.
Check that each rule is stated once, and 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. Define each one in prose, or as a Personalization question. Leave a choice to the builder only when its limits are clear.

Optional files are connected#

Make sure every collection is reached from prose or from a link in another record. 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 run in a circle, or must exist both ways, write that on the field (loops: false, mirrored_by).
For art direction and palettes, keep judged intent separate from measured promises, and connect every measured promise to an acceptance test.
For Personalization, give every question a meaningful default, and check that every possible answer still gives a game you would ship.
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 renders; 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 should say what to build, which chapters define it, and how to recognise that it is done. The format requires the stages, but the validator cannot check them. You check them by hand.
Read every acceptance test. Together they should cover the promises that matter most, without prescribing the builder's code or engine.

When this read finds a format question, open the OpenGDD specification. When it finds an open design decision, update the package.