mcpField
G
game-design-docs

game-design-docs

github.com/lvtd-llcDevelopment166 installsUpdated 7w ago
Repository

About game-design-docs

A skill for producing concise, maintainable design documents that guide AI game-building agents across sessions. It structures decisions, open questions, implementation constraints, and validation evidence.

Key features

  1. 01Chooses a document type
  2. 02Separates intent from implementation details
  3. 03Records decisions and open questions
  4. 04Links specs to project artifacts
  5. 05Defines implementation and maintenance rules

Use cases

  1. 01Aligning a game team on design intent
  2. 02Preparing an implementation brief for an agent
  3. 03Recording playtest findings or design decisions

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/lvtd-llc/skills --skill game-design-docs

After installing, type/game-design-docsin Claude Code to confirm it loaded.

Bundled filesreferences/core/guide.mdworkflows/living-design-doc.md

Details

From the project README

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

  1. Decide the document's job: alignment, implementation, content production, tuning, playtest, or memory.
  2. Keep stable intent separate from volatile implementation details.
  3. Capture decisions, rejected alternatives, open questions, and validation evidence.
  4. Link specs to code, data, assets, tests, and telemetry when possible.
  5. 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.md
  • workflows/living-design-doc.md

Comments

Markdown supported