unikit-gd-spec

Solid

Create and own the master game design document (GAME.md — the authored one-pager plus the generated [gen] system/flow maps) and the GD-IDS.yaml facts registry — the top-level, big-picture layer of the GDD and the machine interface the code side reads. Use it to write the master spec from a concept or dialogue, import an existing GDD (a file path or URL), edit GAME.md content ("change a pillar", "rework the monetization stance", "tweak the loop stack"), pitch the game ("pitch" → PITCH.md), re-decompose the systems ("remap"), and — importantly — to add a new system to the design map ("let's add a new system", "add a crafting system to the game design", "add this to the GDD"). This is the structural, map-level layer plus GAME.md content edits. To write or fill in the detailed parameters of one existing system, use /unikit-gd-system; to apply one edit spanning several zones at once use /unikit-gd-apply; to invent a brand-new game concept use /unikit-gd-brainstorm.

Data & Documents 16 stars 1 forks Updated 5 days ago MIT

Install

View on GitHub

Quality Score: 84/100

Stars 20%
41
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Game Design — Master Spec & System Map Author the **whole-game truth** and the **map of every system**. This skill owns the **spec / map zone** in `.unikit/gamedesign/` (`gd-principles` → Zone Ownership): - **`GAME.md`** — the one-page master GDD. This skill owns **both halves**: the **authored one-pager** (premise, pillars, loop stack, win/lose intent, monetization stance, non-goals) and the **generated `[gen]` maps** at the bottom (`## System Map [gen]` / `## Flow Map [gen]` / `## Funnel [gen]`), which are mechanical read-only re-renders of `GD-IDS.yaml`. Both **content edits** to its sections and **structure** edits (which systems exist, remap) live here — there is no separate editor skill. - **`GD-IDS.yaml`** — the machine-truth registry of pillars, systems, flows, and facts, **and the interface the code side reads** (`unikit-plan` / `unikit-verify` / `unikit-explore`). Optionally it produces **`PITCH.md`**. Per-system detail (`systems/<slug>.md`) is **not** this skill's job — that is `unikit-gd-system`; player-action flows (`flows/<slug>.md`) are `unikit-gd-flow`'s; content types (`content-types/CT-<slug>.md`) are `unikit-gd-content`'s. This skill remains the **single writer of the system roster**: a flow's `GOAL → SYS` or a content type's `belongs_to` that needs a missing system routes back here for add-system. ## Language Awareness — BLOCKING PRE-REQUISITE **BEFORE producing ANY output**, silently read `.unikit/system/LANGUAGE_RULES.md` and apply i...

Details

Author
NintendaDev
Repository
NintendaDev/unikit-ai
Created
3 months ago
Last Updated
5 days ago
Language
Shell
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

API & Backend Solid

unikit-gd-system

Author and own ONE system's design document (the A–K SYSTEM GDD) at .unikit/gamedesign/systems/SYS-<slug>.md — the depth layer of the GDD, single-system scope. Create the skeleton and walk the collaborative section-cycle to write its parameters, rules, formulas, and acceptance criteria ("detail the combat system", "write the GDD for the inventory system", "fill in the rest of this system doc", "spec out the parameters of X"), AND revise it after approval under the delta discipline ("raise the damage by 10%", "tune the economy", "rework the status system", "nerf X", "change this rule") — a number change is Tuning, a small rule a Tweak, restructuring a Rework; each bumps the version and logs the delta. To add a NEW system or restructure the system map use /unikit-gd-spec; to edit GAME.md content use /unikit-gd-spec; the moment an edit also touches a second system, a content type, a flow, or GAME.md (two or more zones) use /unikit-gd-apply; to invent a brand-new game concept use /unikit-gd-brainstorm.

16 Updated 5 days ago
NintendaDev
API & Backend Solid

unikit-gd-flow

Author and own one flow's design document (the FLOW.md objective flow) at .unikit/gamedesign/flows/FLOW-<slug>.md — the dynamics layer of the GDD (what the player does over time). Create the skeleton and walk the collaborative section-cycle to write its objectives, pacing, dependencies, and funnel events ("design the first-session flow", "map the onboarding sequence", "write the FLOW for the boss encounter"), AND revise it after approval under the delta discipline ("retune the pacing", "add a branch", "change a GOAL", "rework the onboarding") — a cue/number change is Tuning, a small step change a Tweak, restructuring a Rework; each bumps the version and logs the delta. Selects the wiring mode (linear | conditional | emergent) and re-renders the ## Flow Map [gen] / ## Funnel [gen] blocks in GAME.md. To add or detail a system use /unikit-gd-system; to edit GAME.md content use /unikit-gd-spec; to apply a multi-zone edit use /unikit-gd-apply; for a new game concept use /unikit-gd-brainstorm.

16 Updated 5 days ago
NintendaDev
Data & Documents Solid

unikit-gd-docs

Render the GAME-DESIGN document (the GDD) into a human-readable form — read-only Markdown chapters under docs/design/ (index, systems, flows, content, economy, glossary), with facts resolved inline from GD-IDS.yaml and drafts flagged 🚧. Optional --web also renders an HTML site from the unikit-docs template (falls back to Markdown-only if the template is absent). Use to export or publish the design for people to read, e.g. "render the GDD", "export the game design to docs", "generate readable design docs", "publish the GDD", "make a design doc site". Read-only — it never edits the GDD or registry, only renders it. This renders the game DESIGN — for the project's CODE documentation (README, docs/*, modules, architecture) use /unikit-docs.

16 Updated 5 days ago
NintendaDev