Game Design Docs
Use this skill to create documents that help an AI game-building agent make consistent decisions across sessions. The document should be short enough to stay current and specific enough to constrain implementation.
Source Traceability
Primary source: The Art of Game Design: A Book of Lenses, Third Edition by Jesse Schell, especially chapter 27 on design documents and team communication. The workflow is transformed and paraphrased.
Supporting source: the rest of the game skill pack, which turns design lenses into implementable briefs.
Workflow
- Decide the document's job: alignment, implementation, content production, tuning, playtest, or memory.
- Keep stable intent separate from volatile implementation details.
- Capture decisions, rejected alternatives, open questions, and validation evidence.
- Link specs to code, data, assets, tests, and telemetry when possible.
- Update docs after design decisions, not after every small code edit.
Required Output
Doc Type: brief, system spec, feature contract, tuning sheet, content schema, playtest report, or decision log.Canonical Sections: concise headings suited to the doc type.Open Questions: unresolved decisions with owner or next evidence.Implementation Contract: what the agent should build, avoid, test, and instrument.Maintenance Rule: when this doc must be updated.
Local References
Before producing a design document, read:
references/core/guide.mdworkflows/living-design-doc.md
Source: hashgraph-online/awesome-codex-plugins → plugins/LVTD-LLC/skills/skills/game-design-docs/SKILL.md
1---2name: game-design-docs3description: Create lightweight, living game design documents for AI-built games. Use when writing a game design brief, system spec, feature contract, content schema, implementation handoff, decision log, or when a coding agent needs durable project memory.4---567# Game Design Docs89Use this skill to create documents that help an AI game-building agent make consistent decisions across sessions. The document should be short enough to stay current and specific enough to constrain implementation.1011## Source Traceability1213Primary source: *The Art of Game Design: A Book of Lenses, Third Edition* by Jesse Schell, especially chapter 27 on design documents and team communication. The workflow is transformed and paraphrased.1415Supporting source: the rest of the game skill pack, which turns design lenses into implementable briefs.1617## Workflow18191. Decide the document's job: alignment, implementation, content production, tuning, playtest, or memory.202. Keep stable intent separate from volatile implementation details.213. Capture decisions, rejected alternatives, open questions, and validation evidence.224. Link specs to code, data, assets, tests, and telemetry when possible.235. Update docs after design decisions, not after every small code edit.2425## Required Output2627- `Doc Type`: brief, system spec, feature contract, tuning sheet, content schema, playtest report, or decision log.28- `Canonical Sections`: concise headings suited to the doc type.29- `Open Questions`: unresolved decisions with owner or next evidence.30- `Implementation Contract`: what the agent should build, avoid, test, and instrument.31- `Maintenance Rule`: when this doc must be updated.3233## Local References3435Before producing a design document, read:3637- `references/core/guide.md`38- `workflows/living-design-doc.md`3940---4142**Source:** [`hashgraph-online/awesome-codex-plugins`](https://github.com/hashgraph-online/awesome-codex-plugins) → `plugins/LVTD-LLC/skills/skills/game-design-docs/SKILL.md`
thedixitjain