This skill should be used when the user asks to "design a game mechanic", "evaluate gameplay feel", "tune game systems", "review player experience", "debug why something feels wrong", "balance combat", "design progression", or when working on any player-facing game feature. Provides a constraint system for evaluating mechanics with focus on player experience over feature completion.
Analyzes game mechanics through a five-component framework focused on player experience, clarity, and balance.
npx claudepluginhub rbergman/dark-matter-marketplaceThis skill inherits all available tools. When active, it can use any tool Claude has access to.
references/5-component-rubric.mdreferences/domain-guide.mdreferences/templates.mdPurpose: Central evaluation framework for game mechanics. Use this as the first pass on any feature — the 5-Component Filter identifies what's weak, then specialized skills provide deep guidance.
Core principle: Mechanics are code. Gameplay is the player's experience of that code. The goal is not to implement features, but to implement Relevance.
Influences: The 5-Component Framework synthesizes principles from Tynan Sylvester (experience engineering), Celia Hodent (cognitive UX), and Ian Schreiber (balance methodology).
Before implementing or critiquing ANY game feature, evaluate against:
| Component | Core Question | Quick Check |
|---|---|---|
| Clarity | Can the player predict what will happen? | Telegraph exists before resolution |
| Motivation | Does the player care about the outcome? | Outcome affects persistent state |
| Response | Do player inputs matter? | Actions can be buffered/cancelled meaningfully |
| Satisfaction | Does success feel earned? | Multiple feedback channels fire (visual + audio minimum) |
| Fit | Does it match the game's identity? | Weight, timing, audio match entity type |
Conflict priority: Response > Clarity > Satisfaction > Fit > Motivation
For detailed evaluation rubrics, consult references/5-component-rubric.md.
references/domain-guide.mdWhen proposing ANY numeric value (timing windows, costs, speeds, damage, etc.), choose ONE:
Option A — Source-backed:
Option B — Starting value with test plan:
Never claim "industry standard" or "common practice" without a source.
When critical information is missing, state explicitly:
ASSUMPTION: [what you're assuming]
IMPACT: [why it matters to the design]
IF WRONG: [failure mode]
VALIDATE: [how to check quickly]
Search before proposing when:
If search unavailable, convert to "Assumption + Test Plan" format.
For ANY feature that changes player state (movement abilities, combat actions, status effects):
| Property | Must Define |
|---|---|
| Entry conditions | What states can transition INTO this? |
| Exit conditions | What ends this state? (timer, input, external event) |
| Interruptibility | What can cancel this? (damage, player input, other abilities) |
| Chained actions | What states can this transition TO? |
| Resource cost | What is consumed on entry? On sustain? |
| Edge cases | Behavior on: slopes, ceilings, moving platforms, during hitstun, at resource zero |
When told "it feels wrong/boring/clunky," diagnose in order:
| Symptom | Check First | Before Tuning Numbers | Deep Dive |
|---|---|---|---|
| "I didn't know that would happen" | Clarity | Add telegraph, audio cue, UI indicator | player-ux |
| "I don't care" | Motivation | Connect to progression, increase stakes | experience-design |
| "It feels laggy" | Response | Add buffering, allow cancels, reduce lockouts | game-feel |
| "It feels weak" | Satisfaction | Add feedback channels (minimum 2) | game-feel |
| "It doesn't fit" | Fit | Adjust timing, weight, audio texture | game-feel |
| "It's not balanced" | Balance | Check cost curves, dominant strategies | game-balance |
| "It's boring" | Engagement | Check loop, pacing, meaningful choice | experience-design |
| "It's too hard/easy" | Progression | Check flow channel, difficulty curve | progression-systems |
Rule: Do not tune damage/timing numbers until Clarity and Response are verified as not the root cause.
Every significant feature must include scenarios for:
When proposing or critiquing a feature:
After the 5-Component Filter identifies a weakness, go deeper:
| Area | Skill | When to Use |
|---|---|---|
| Balance & economy | game-balance | Cost curves, dominant strategies, economy sinks/sources |
| Engagement & pacing | experience-design | Core loops, emotion layering, "why isn't this fun?" |
| Cognitive load & UI | player-ux | Perception/attention/memory, Gestalt UI, onboarding |
| Difficulty & leveling | progression-systems | Power curves, flow channel, XP math, unlock pacing |
| Feedback & juice | game-feel | Juice checklists, timing, "why does this feel bad?" |
| Testing & validation | playtest-design | Question generation, observation protocols, metrics |
| Per-frame performance | game-perf | Zero-allocation patterns for hot paths |
| Project bootstrapping | pixi-vector-arcade | PixiJS 8 setup with vector aesthetics |
For detailed guidance:
references/5-component-rubric.md - Full evaluation rubrics with signals, rules, knobs, acceptance testsreferences/domain-guide.md - Combat, movement, camera, audio, UI/UX, progression, persistence domainsreferences/templates.md - Edge case enumeration, debugging flow, playtest scriptsActivates when the user asks about AI prompts, needs prompt templates, wants to search for prompts, or mentions prompts.chat. Use for discovering, retrieving, and improving prompts.
Search, retrieve, and install Agent Skills from the prompts.chat registry using MCP tools. Use when the user asks to find skills, browse skill catalogs, install a skill for Claude, or extend Claude's capabilities with reusable AI agent components.
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.