New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Quick Design Spec

by Donchitos in Donchitos/Claude-Code-Game-Studios

Writes a short design spec for small gameplay adjustments such as tuning, tweaks and minor additions, and redirects anything larger to a full design document.

MITAuto-check passedGame Development

Install Quick Design Spec

skills CLI
$ npx skills add Donchitos/Claude-Code-Game-Studios --skill quick-design -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install Donchitos/Claude-Code-Game-Studios quick-design --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/Donchitos/Claude-Code-Game-Studios.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/quick-design .claude/skills/quick-design && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
quick-design
GitHub stars
26k
Token cost
~2.9k tokens
SKILL.md length
1,040 words
Files
1
Skills in repo
73
Repo updated
First seen
Licence
MIT

At a glance

Writes a short design spec for small gameplay adjustments such as tuning, tweaks and minor additions, and redirects anything larger to a full design document.

  • Works in 5 steps: Classify the Change → Context Scan → Draft the Quick Design Spec → …
  • Documenting a balance or tuning change that needs a rationale but not a full GDD
  • SKILL.md covers 1. Classify the Change, 2. Context Scan, 3. Draft the Quick Design Spec and 4. Approval and Filing, plus 2 more sections
  • Calls bash

What it does

This is the light path for changes that do not justify a full design document, meaning work under about one week of implementation. The agent classifies the request as tuning, a tweak, an addition or a new small system. Examples include raising jump height, letting a dash be invincible on its first frame, adding a parry window or building an achievement popup.

If the change adds a system with heavy cross-system dependencies, needs more than a week or rewrites the core rules of an existing system, the skill stops and sends you to `/design-system`. Otherwise it confirms the classification and writes a spec under `design/quick-specs/` with the change name and date, so the change has a written rationale that can be embedded into stories.

When your agent uses it

  • Documenting a balance or tuning change that needs a rationale but not a full GDD
  • Specifying a small mechanic addition to an existing system
  • Deciding whether a change is small enough to skip the full design process

Example prompts

  • “Write a quick design for letting the dash cancel into a roll.”
  • “Spec a tuning change that reduces enemy patrol speed by 10%.”
  • “Add a parry window to the block mechanic and document it as a quick spec.”

Requirements

  • Pre-approved tools (allowed-tools): Read, Glob, Grep, Write, Edit, AskUserQuestion, Bash(bash "*/.claude/skills/quick-design/../../hooks/yaml-helper.sh" resolve_config *)

Workflow steps

5 steps, taken from the step headings in SKILL.md.

  1. Classify the Change
  2. Context Scan
  3. Draft the Quick Design Spec
  4. Approval and Filing
  5. Handoff

What it can do on your machine

Read from SKILL.md and the folder at commit b21fa0f. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • Read
    • Glob
    • Grep
    • Write
    • Edit
    • AskUserQuestion
    • Bash(bash "*/.claude/skills/quick-design/../../hooks/yaml-helper.sh" resolve_config *)

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • bash

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Quick Design Spec loads about 2.9k tokens when it runs. Until then it costs about 33 tokens; SKILL.md has 1,040 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~33
When it runs · the whole SKILL.md, loaded when a task matches
~2.9k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from Donchitos/Claude-Code-Game-Studios at commit b21fa0f, republished under its MIT licence (© Donchitos). 1,040 words, ~2,892 tokens.

Download SKILL.mdSave it as .claude/skills/quick-design/SKILL.md (or your agent's skills folder).
name
quick-design
description
Lightweight spec for small changes — tuning adjustments, minor mechanics. Embeds directly into stories; skips full GDD.
allowed-tools
Read, Glob, Grep, Write, Edit, AskUserQuestion, Bash(bash "*/.claude/skills/quick-design/../../hooks/yaml-helper.sh" resolve_config *)
argument-hint
[brief description of the change]
user-invocable
true
model
sonnet

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys automation,workflow

Quick Design

This is the lightweight design path for changes that don't need a full GDD. Full GDD authoring via /design-system is the heavyweight path. Use this skill for work under about one week of implementation — tuning adjustments, minor behavioral tweaks, small additions to existing systems, or standalone features too small to warrant a full document. Most tweaks are hours; the one-week ceiling is the limit for a New Small System (see the categories below).

Output: design/quick-specs/[name]-[date].md

When to run: Anytime a change is too small for /design-system but too meaningful to implement without a written rationale.

Every AskUserQuestion call follows .claude/docs/automation-modes.md (collaborative asks always · guided major-only · autonomous logs and proceeds; automation_always_ask categories always prompt).

1. Classify the Change

First, read the argument and determine which category this change falls into:

  • Tuning — changing numbers or balance values in an existing system with no behavioral change (most minimal path). Example: "increase jump height from 5 to 6 units", "reduce enemy patrol speed by 10%".
  • Tweak — a small behavioral change to an existing system that introduces no new states, branches, or systems. Example: "make dash invincible on frame 1", "allow combo to cancel into roll".
  • Addition — adding a small mechanic to an existing system that may introduce 1-2 new states or interactions. Example: "add a parry window to the block mechanic", "add a charge variant to the basic attack".
  • New Small System — a standalone feature small enough that it has no existing GDD and is under approximately one week of implementation work. Example: "achievement popup system", "simple day/night visual cycle".

If the change does NOT fit these categories — it introduces a new system with significant cross-system dependencies, requires more than one week of implementation, or fundamentally alters an existing system's core rules — stop and redirect to /design-system instead. Verdict: REDIRECTED — use /design-system for this change.

If there is no argument, ask the user to describe the change (plain text prompt), then classify it using the criteria above.

Present the inferred classification using AskUserQuestion:

  • Prompt: "I've classified this as [inferred type] — [brief reason]. Is that correct?"
  • Options:
    • [A] Yes — [inferred type] is correct
    • [B] Tuning — changing numbers or balance values only
    • [C] Tweak — small behavioral change to an existing system
    • [D] Addition — adding a small mechanic to an existing system
    • [E] New Small System — standalone feature, under one week of work
    • [F] This is too large — redirect me to /design-system

If [F]: stop. Verdict: REDIRECTED — use /design-system for this change. Otherwise: proceed with the selected type.

2. Context Scan

Before drafting anything, read the relevant context:

  • Search design/gdd/ for the GDD most relevant to this change. Read the sections that this change would affect. If no GDD covers this system — usually the case at workflow: minimal, where design/game-brief.md and the stories are the design record — read the brief's lines for it and the story the change touches instead, report "No GDD for [system] — using the brief and [story path]", and give the brief as the spec's GDD Reference.
  • Check whether design/gdd/systems-index.md exists. If it does, read it to understand where this system sits in the dependency graph and what tier it belongs to. If it does not exist, note "No systems index found — skipping dependency tier check." and continue.
  • Check design/quick-specs/ for any prior quick specs that touched this system — avoid contradicting them.
  • If this is a Tuning change, also check assets/data/ for the data file that holds the relevant values.

Report what was found: "Found GDD at [path]. Relevant section: [section name]. Prior quick specs for this system: [each path, and whether it agrees or conflicts with this change — or "none"]." Name a prior spec even when it agrees — "no conflicts" alone reads the same as "no prior specs".

Show full SKILL.md (418 more words)Show less

3. Draft the Quick Design Spec

Use the appropriate spec format for the change category.

For Tuning changes

Produce a single table:

markdown
# Quick Design Spec: [Title]

**Type**: Tuning
**System**: [System name]
**GDD Reference**: `design/gdd/[filename].md` — Tuning Knobs section
**Date**: [today]

## Change

| Parameter | Old Value | New Value | Rationale |
|-----------|-----------|-----------|-----------|
| [param]   | [old]     | [new]     | [why]     |

## Tuning Knob Mapping

Maps to GDD Tuning Knob: [knob name and its documented range].
New value is [within / at the edge of / outside] the documented range.
[If outside: explain why the range should be extended.]

## Acceptance Criteria

- [ ] [Parameter] reads [new value] from `assets/data/[file]`
- [ ] Behavior difference is observable in [specific context]
- [ ] No regression in [related behavior]
For Tweak and Addition changes
markdown
# Quick Design Spec: [Title]

**Type**: [Tweak / Addition]
**System**: [System name]
**GDD Reference**: `design/gdd/[filename].md`
**Date**: [today]

## Change Summary

[1-2 sentences describing what changes and why.]

## Motivation

[Why is this change needed? What player experience problem does it solve?
Reference the relevant MDA aesthetic or player feedback if applicable.]

## Design Delta

Current GDD says (quoting `design/gdd/[filename].md`, [section]):

> [exact quote of the relevant rule or description]

This spec changes that to:

[New rule or description, written with the same precision as a GDD Detailed
Rules section. A programmer should be able to implement from this text alone.]

## New Rules / Values

[Full unambiguous statement of the replacement content. If this introduces
new states, list them. If it introduces new parameters, define their ranges.]

## Affected Systems

| System | Impact | Action Required |
|--------|--------|-----------------|
| [system] | [how it is affected] | [update GDD / update data file / no action] |

## Acceptance Criteria

- [ ] [Specific, testable criterion 1]
- [ ] [Specific, testable criterion 2]
- [ ] [Specific, testable criterion 3]
- [ ] No regression: [the original behavior this must not break]

## GDD Update Required?

[Yes / No]
[If yes: which file, which section, and what the update should say.]
For New Small System changes

Use a trimmed GDD structure. Include only the sections that are directly necessary — skip Player Fantasy, full Formulas, and Edge Cases unless the system specifically requires them.

markdown
# Quick Design Spec: [Title]

**Type**: New Small System
**Scope**: [1-2 sentence description of what this system does and doesn't do]
**Date**: [today]
**Estimated Implementation**: [hours]

## Overview

[One paragraph a new team member could understand. What does this system do,
when does it activate, and what does it produce?]

## Core Rules

[Unambiguous rules for the system. Use numbered lists for sequential behavior
and bullet lists for conditions. Be precise enough that a programmer can
implement without asking questions.]

## Tuning Knobs

| Knob | Default | Range | Category | Rationale |
|------|---------|-------|----------|-----------|
| [name] | [value] | [min–max] | [feel/curve/gate] | [why this default] |

All values must live in `assets/data/[appropriate-file].json`, not hardcoded.

## Acceptance Criteria

- [ ] [Functional criterion: does the right thing]
- [ ] [Functional criterion: handles the edge case]
- [ ] [Experiential criterion: feels right — what a playtest validates]
- [ ] [Regression criterion: does not break adjacent system]

## Systems Index

This system is not currently in `design/gdd/systems-index.md`.
[If it should be added: suggest which layer and priority tier.]
[If it is too small to track: state "This system is below systems-index
tracking threshold — quick spec is sufficient."]

4. Approval and Filing

Present the draft to the user in full. Then use AskUserQuestion:

  • Prompt: "Here's the Quick Design Spec draft. How do you want to proceed?"
  • Options:
    • [A] Approve — write it as shown
    • [B] Revise — I'll describe what to change
    • [C] This grew too large — redirect to /design-system instead

If [B]: collect the requested changes, revise the draft, and re-present this widget. If [C]: stop. Verdict: REDIRECTED — use /design-system for this change.

If [A]: ask "May I write this Quick Design Spec to design/quick-specs/[kebab-case-title]-[YYYY-MM-DD].md?"

Use today's date in the filename. The title should be a kebab-case description of the change (e.g., jump-height-tuning-2026-03-10, parry-window-addition-2026-03-10).

If yes, create the design/quick-specs/ directory if it does not exist, then write the file.

If a GDD update is required (flagged in the spec), ask separately after writing the quick spec:

"This spec modifies rules in [System Name]. May I update design/gdd/[filename].md — specifically the [section name] section?"

Show the exact text that would be changed (old vs. new) before asking. Do not make GDD edits without explicit approval.

5. Handoff

After writing the file, output:

Quick Design Spec written to: design/quick-specs/[filename].md
Type: [Tuning / Tweak / Addition / New Small System]
System: [system name]
GDD update: [Required — pending approval / Applied / Not required]

Next step: This spec is ready for `/story-readiness` validation before
implementation (at `workflow: minimal`, go straight to `/dev-story`). Reference this spec in the story's GDD Reference field.
Pipeline Notes

Verdict: COMPLETE — quick design spec written and ready for implementation.

Quick Design Specs bypass /design-review and /review-all-gdds by design. They are for small, low-risk, well-scoped changes where the cost of the full review pipeline exceeds the risk of the change itself.

Redirect to the full pipeline if any of the following are true:

  • The change adds a new system that belongs in the systems index
  • The change significantly alters cross-system behavior or a system's contracts with other systems
  • The change introduces new player-facing mechanics that affect the game's MDA aesthetic balance
  • Implementation is likely to exceed one week of work

In those cases: "This change has grown beyond quick-spec scope. I recommend using /design-system to author a full GDD for this."

  • Run /story-readiness [story-path] to validate the story before implementation begins (skip at rigor: minimal — /dev-story directly) — reference this spec in the story's GDD Reference field
  • Run /dev-story [story-path] to implement once the story passes readiness checks
  • If the change is larger than expected, run /design-system [system-name] to author a full GDD instead

© Donchitos, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .claude/skills/quick-design of Donchitos/Claude-Code-Game-Studios.

Open the folder on GitHubat commit b21fa0f

Compare with similar skills

Quick Design Spec next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Quick Design Spec compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Quick Design Spec this skillDonchitos/Claude-Code-Game-Studios26k—~2.9kAutomated safety check: PassMIT
Threejs Gameplay Systemsvalkor-ai/loom1.2k1 repos~1.4kAutomated safety check: PassApache-2.0
Godot Gdscript Patterns925236118/AlphaAgent1039 repos~5kAutomated safety check: PassMIT
Novel Game Adaptation Analysiszenstory-ai/novel-to-game8321 repos~558Automated safety check: PassMIT
Game Experience Density OptimizerDY-2026/GameDesignOS410—~2.1kAutomated safety check: PassMIT
Threejs Gameplay Systemscorosolto/client256—~1.5kAutomated safety check: PassAGPL-3.0

Similar skills

  • Threejs Gameplay Systems

    valkor-ai/loom

    Build and iterate playable Three.js game systems: starter scaffold, architecture, design briefs, core loops, level and encounter design, entities, input, camera, collision and physics, scoring…

    1.2k GitHub starsUsed in 1 repo~1.4k tokens
    Game DevelopmentAuto-check passed

  • Godot Gdscript Patterns

    925236118/AlphaAgent

    Master Godot 4 GDScript patterns including signals, scenes, state machines, and optimization.

    103 GitHub starsUsed in 9 repos~5k tokens
    Game DevelopmentAuto-check passed

  • Novel Game Adaptation Analysis

    zenstory-ai/novel-to-game

    Condenses a novel or its deconstruction notes into a cited SOURCE_BIBLE of world rules, player verbs, spaces and systems, before any game genre is chosen.

    832 GitHub starsUsed in 1 repo~558 tokens
    Game DevelopmentAuto-check passed

  • Game Experience Density Optimizer

    DY-2026/GameDesignOS

    当用户需要把游戏体验浓度、留存、首局节奏、Demo 完成率、单机总旅程、D1/D7、反馈、具身感、氛围、认知负荷、最佳刺激窗口、FEP/free-energy、预测误差、Markov blanket、习惯化或 liveops 参与问题，编译成可上线、可埋点、可复盘、可回滚的一周 ED 实验包时使用。Use when converting game experience-density and…

    410 GitHub stars~2.1k tokensUpdated 1 mo ago
    Game DevelopmentAuto-check passed

  • Threejs Gameplay Systems

    corosolto/client

    Build and iterate playable Three.js game systems. An agent skill from corosolto/client.

    256 GitHub stars~1.5k tokensUpdated today
    Game DevelopmentAuto-check passed

  • Roblox Game

    brockmartin/roblox-game-skill

    Expert Roblox game development companion — Luau, Roblox Studio, MCP integration, simulator, tycoon, obby, RPG, horror, battle royale, game design, security, performance.

    197 GitHub stars~1.3k tokensUpdated 7 mo ago
    Game DevelopmentAuto-check passed

More from Donchitos/Claude-Code-Game-Studios

All 73 skills in this repo

  • Game Asset Audit

    Donchitos/Claude-Code-Game-Studios

    Audits game assets against naming conventions, file size budgets and format standards, and finds orphaned assets and missing references.

    26k GitHub stars~2k tokensUpdated 8 days ago
    Auto-check passed

  • Game Asset Spec Writer

    Donchitos/Claude-Code-Game-Studios

    Writes per-asset visual specs and AI image-generation prompts for a game's characters, enemies and screens, driven by the GDD, art bible and an entity inventory.

    26k GitHub stars~5k tokensUpdated 8 days ago
    Auto-check passed

  • Game Balance Check

    Donchitos/Claude-Code-Game-Studios

    Checks game data and formulas for balance outliers, broken progression, degenerate strategies and economy problems, and answers 'could not run' when the data is missing.

    26k GitHub stars~2.2k tokensUpdated 8 days ago
    Auto-check passed

  • Structured Bug Reports

    Donchitos/Claude-Code-Game-Studios

    Turns a description into a structured bug report, or scans code for likely bugs, then verifies and closes reports through four modes.

    26k GitHub stars~2.5k tokensUpdated 8 days ago
    Auto-check: notes

  • Bug Triage

    Donchitos/Claude-Code-Game-Studios

    Reviews the open bug backlog, separates severity from priority, assigns fixes to sprints and reports systemic trends, writing a dated triage file.

    26k GitHub stars~2.3k tokensUpdated 8 days ago
    Auto-check passed

  • Changelog Generator for Games

    Donchitos/Claude-Code-Game-Studios

    Generates an internal or player-facing changelog from git commits and sprint data, filtering out framework maintenance commits so that only work on the game itself reaches release copy.

    26k GitHub stars~2.5k tokensUpdated 8 days ago
    Auto-check: notes

Categories

Questions about Quick Design Spec

What does Quick Design Spec do?

Writes a short design spec for small gameplay adjustments such as tuning, tweaks and minor additions, and redirects anything larger to a full design document. This is the light path for changes that do not justify a full design document, meaning work under about one week of implementation. The agent classifies the request as tuning, a tweak, an addition or a new small system.

When should I use Quick Design Spec?

Quick Design Spec fits situations like: documenting a balance or tuning change that needs a rationale but not a full GDD; specifying a small mechanic addition to an existing system; deciding whether a change is small enough to skip the full design process.

How do I install Quick Design Spec in Claude Code?

Run `npx skills add Donchitos/Claude-Code-Game-Studios --skill quick-design -a claude-code`. Or copy the skill folder (.claude/skills/quick-design in Donchitos/Claude-Code-Game-Studios) into .claude/skills/quick-design in your project. Claude Code loads it when a task matches its description.

How do I install Quick Design Spec in Codex?

Run `npx skills add Donchitos/Claude-Code-Game-Studios --skill quick-design -a codex`. Or copy the skill folder (.claude/skills/quick-design in Donchitos/Claude-Code-Game-Studios) into .agents/skills/quick-design in your project. Codex loads it when a task matches its description.

Can I use Quick Design Spec in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add Donchitos/Claude-Code-Game-Studios --skill quick-design -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/quick-design, .gemini/skills/quick-design, .github/skills/quick-design and .opencode/skills/quick-design in your project.

What does Quick Design Spec need to run?

Going by SKILL.md and its folder, Quick Design Spec needs the command-line tools its instructions call (bash). Its frontmatter pre-approves these tools: Read, Glob, Grep, Write, Edit, AskUserQuestion, Bash(bash "*/.claude/skills/quick-design/../../hooks/yaml-helper.sh" resolve_config *).

Does Quick Design Spec access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Quick Design Spec safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Quick Design Spec use?

Quick Design Spec is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Quick Design Spec use?

About 2.9k tokens (SKILL.md is roughly 12k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Quick Design Spec?

Skills that share tags, products or a category with Quick Design Spec: Threejs Gameplay Systems (valkor-ai/loom, 1.2k stars), Godot Gdscript Patterns (925236118/AlphaAgent, 103 stars), Novel Game Adaptation Analysis (zenstory-ai/novel-to-game, 832 stars) and Game Experience Density Optimizer (DY-2026/GameDesignOS, 410 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Quick Design Spec?

Donchitos (a GitHub user) maintains it in Donchitos/Claude-Code-Game-Studios, which has 25,834 GitHub stars. The repository holds 73 skills in this directory. The repository was last updated on September 29, 2026.

Source: Donchitos/Claude-Code-Game-Studios on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.