unikit-gd-review

Solid

Qualitative quality review of game design documents — answers "is this design good, and does it follow best practices?" — across all three GDD axes: systems, flows, and content types. Fans out adversarial lenses (completeness, clarity, pillar alignment, systems-math, fantasy-delivery, feasibility, scope) plus domain lenses that check it against the game-design rules, each prompted to find problems rather than validate; produces a severity-graded verdict and a two-bucket report (apply-ready fixes vs research), handed to /unikit-gd-apply or /unikit-gd-explore in one move. Scope is inferred: a named system, flow, or content type reviews that document; "all" runs a cross-document review. Use when the user wants a critique, quality judgment, or rules check of the design, e.g. "review the combat GDD", "review the onboarding flow". This is the subjective quality pass — for a mechanical consistency check (numbers, terms, IDs, references matching the registry) use /unikit-gd-verify.

AI & Automation 16 stars 1 forks Updated 5 days ago MIT

Install

View on GitHub

Quality Score: 86/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 — Quality Review Answer **"is this design good?"** — expert judgment on a finished design document, delivered as a severity-graded verdict with evidence. This is the design-side mirror of `unikit-review`. It is distinct from `unikit-gd-verify`, which answers the cheaper, binary **"is the design consistent with itself?"** — a review finding *can* be declined; a verify conflict cannot. The review **ends in a handoff, not a hand-list**: the full report prints to the screen, every finding is triaged into an **apply-ready** bucket (a named entailed fix to apply now) or a **research** bucket (an open question to work out), and the user makes one move — `review → [explore] → apply` — instead of routing findings one at a time into owner skills. The triage engine (the ENTAILED criterion + the interview) is shared with `unikit-gd-verify` and lives in `gd-critique` → Handoff Engine. Review is **axis-aware**: it judges **systems** (the A–K GDD), **flows** (`FLOW.md` + the `## Flow Map [gen]` / `## Funnel [gen]` renders), and **content types** (`CONTENT-TYPE.md` + the `## Content Map [gen]` render). The flow lenses — pacing / guidance / funnel — and the content lenses — schema-coherence / catalog-scale / content-fantasy-delivery — live in `references/lenses.md` alongside the system lenses. A review is most honest in a **fresh session** — the reviewer should not be the author of the document. This skill never authors or edits design **content**, and it **never writes a `d...

Details

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

Similar Skills

Semantically similar based on skill content — not just same category

Code & Development Solid

unikit-gd-verify

Mechanical consistency check for game design — answers "is the design consistent with itself?" — plus changed-scope impact analysis across all three GDD axes: systems, flows, and content types. Offline and deterministic: greps the facts registry against the documents (numbers, terms, IDs, duplicate & dangling references, roster↔disk, map freshness, Depends 3-way, status/version, AC presence, placeholder leaks, flow & content schema), and from a git diff computes which dependent systems, flows, and content a change affects. Scope is inferred: a named document checks that document; an unverified diff triggers a changed-scope pass; otherwise everything. Use when the user wants a consistency or impact check, e.g. "verify the design", "what did this change affect", "find broken references in the design". Conflicts triage into four tracks; the entailed fixes hand off to /unikit-gd-apply in one pass. This is the mechanical pass — for a subjective "is this design good" quality critique use /unikit-gd-review.

16 Updated 5 days ago
NintendaDev
Code & Development Listed

game-design-review

Review, critique, compare, improve, or stress-test an existing game concept, GDD, mechanic, puzzle, economy, level, theme, emotional arc, interface, narrative, social feature, prototype, pitch, or playtest result. Use when the user asks what is weak, risky, unclear, unbalanced, contradictory, insufficiently engaging, or worth validating next in a game design. Produce evidence-based findings, explicit tradeoffs, and the smallest useful prototype or playtest experiment.

68 Updated 2 weeks ago
Yuki001
Code & Development Listed

craft-review

Rigorous visual and UX design review for UI screens and flows. Use when the user asks to review a design, critique a screen, audit a UI, check spacing, alignment, hierarchy, typography, color, contrast or accessibility, asks whether something looks polished, off, or generically AI-generated, or shares a screenshot or Figma URL for feedback. Measures before it judges, and reports severity-ranked findings with numeric fixes. NOT for turning mocks into a decision page (use decision-artifact) and NOT for prose (use natural-writing).

1 Updated 1 weeks ago
LarrySequino