game-design
Game design
Ownership
Own the intended player experience and the rules that produce it: fantasy, pillars, verbs, decisions, feedback, loops, resources, progression, challenge, failure, onboarding, and social dynamics. Treat design claims as hypotheses proved by play, not a feature inventory or genre imitation — no genre kits, presets, or archetypes; every game is a custom composition of needs (see AGENTS.md).
Use level-design for spatial realization; route implementation to jgengine-gameplay, jgengine-world, jgengine-combat, jgengine-ui, jgengine-multiplayer once intent is coherent.
For a substantial existing-game quality pass spanning concept, depth, world and presentation, use game-improvement to sequence these owners and keep a per-game implementation plan and acceptance evidence.
For a greenfield build, read references/application-playbook.md and produce its greenfield contract (promise, pillars, anti-pillars, core decision, and falsifier) before writing code. Audits may read only the playbook's audit sections. Read references/field-guide.md when the task needs deeper loop, economy, progression, genre, accessibility, or research guidance.
Choose the mode
Greenfield: produce a vertical-slice contract (promise, pillars, core decision, loops, progression, failure/recovery) and build the smallest slice testing the riskiest assumption — see playbook §1. Existing game: reconstruct what it actually does from code and play, rank root problems by impact/confidence/reach/effort — see playbook §2.
“Improve with game design” is an implementation request, not just an audit: select the highest-leverage intervention, implement it through shared engine seams, and prove the changed player behavior.