doc-design

Guides design of game configuration Docs as JSON schemas for editor forms.

5|Updated May 5, 2026
One-click install
npx skills add https://github.com/ababup1192/flix_game_engine --skill doc-design-ababup1192
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: doc-design
Source: https://github.com/ababup1192/flix_game_engine/tree/main/.claude/skills/doc-design
Command: npx skills add https://github.com/ababup1192/flix_game_engine --skill doc-design-ababup1192

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Deciding which game values belong in external JSON Docs versus code, how to split Docs by concern, and how to structure schemas so the Studio editor renders usable forms is error-prone; this Skill codifies those design decisions. ## Core Features & Use Cases - Externalize vs. code decisions: Criteria for which values (tunable numbers, lists, color themes) go into JSON Docs and which stay in code. - Doc splitting rules: One Doc per concern, with concrete split signals such as 5+ same-prefix keys, 30+ scalars, or 16+ list items. - Schema dialect reference: The five Studio-supported kinds (value/field, record, catalog/map, list) plus common mistakes that silently break form rendering. - Use Case: When adding a new tunable section to a game like harvest.kind.json, use this Skill to decide the Doc boundaries and schema shape so the editor shows grouped tabs instead of 29 flat fields. ## Quick Start Use the doc-design skill to review my new game configuration JSON and tell me how to split it into Docs and which schema kinds to declare.

Frequently Asked Questions about doc-design

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide which game values to put in JSON config files?

Externalize values you tune repeatedly (tempo, thresholds, probabilities), data that grows in count (enemies, items), and color themes. Keep rendering algorithms, choreography, and derivable values in code; writing logic into JSON signals a design problem.

How should I split a large JSON config into multiple documents?

Split by concern using the rule of when you re-read the data. Signals include 5+ keys sharing a prefix, 30+ scalars, or 16+ list items; for example a 29-field harvest config split into an 11-field tuning Doc and a 19-field paint Doc.

Why is my JSON schema not rendering as a form in the editor?

The Studio editor only renders five schema kinds: value/field, record, catalog/map, and list; anything else falls back to raw JSON editing. Common mistakes include writing item instead of fields, using number/string/boolean instead of float/int/text/bool, or non-integer order values.

What schema types does the Studio editor support for config forms?

Five kinds are supported: value or field for single scalars, record for nested groups, catalog or map for name-keyed dictionaries, and list for ordered sequences. Field types include float, int, text, bool, color, vec2, grid, enum, and ref.

When should I use group instead of splitting a Doc?

Use group to bundle 5+ related single values so tabs do not multiply, but do not use it as an excuse to avoid splitting. First check whether the Doc mixes separate concerns with different lifecycles, which should become separate Docs.