quick-design

Solid

Lightweight design spec for small changes — tuning adjustments, minor mechanics, balance tweaks. Skips full GDD authoring when a system GDD already exists or the change is too small to warrant one. Produces a Quick Design Spec that embeds directly into story files.

Web & Frontend 85 stars 8 forks Updated 1 months ago MIT

Install

View on GitHub

Quality Score: 87/100

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

Skill Content

# 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 approximately 4 hours of implementation — tuning adjustments, minor behavioral tweaks, small additions to existing systems, or standalone features too small to warrant a full document. **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. --- ## 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 vi...

Details

Author
striderZA
Repository
striderZA/OpenCodeGameStudios
Created
4 months ago
Last Updated
1 months ago
Language
JavaScript
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Listed

specdd

Spec-driven development orchestrator that turns vague, top-of-mind feature requests into production-grade specifications before any code is written. ALWAYS use this skill whenever the user describes a feature, change, capability, screen, flow, or new component in plain language — even if they don't explicitly ask for a spec. Triggers on phrases like "build me", "make me", "add a feature", "I want to", "help me create", "implement", "let's build", "I need a", "can you make", "create a screen/page/component", or any new-feature request that lacks complete requirements (missing user stories, acceptance criteria, edge cases, error/empty/loading states, accessibility, or non-functional requirements). Interviews the user to fill gaps, applies UX/UI common sense, produces a structured spec + plan + tasks, then implements against the spec. Use this BEFORE writing any code for non-trivial features. Skip only for true one-liners (rename a variable, fix a typo, answer a research question) or work that is purely investig

2 Updated today
mnyok9939
Web & Frontend Featured

design

Writes a clear spec for a proposed feature or system change. Use when important product or technical choices must be settled before coding. Covers behavior, interfaces, failures, risks, acceptance criteria, and tests. Use architecture to explain the current system.

390 Updated 4 days ago
owainlewis
Web & Frontend Listed

ds-specs

Build and maintain an LLM-readable design system that is also a two-way bridge to Figma — a three-tier spec tree (foundations/tokens → components → patterns), a closed token layer with three-layer indirection, a CI-ready audit script that blocks hardcoded values, and a reconcile report that diffs Figma variables, component sets, variants, and bindings against the specs. Use this skill whenever the user says "create a design system," "set up a design system," "make my design system LLM-readable," "tokenize this," "write specs for my components," "my prototype is drifting," or "the AI keeps picking different colors." ALSO use it for any syncing between Figma and code — "push my specs to Figma," "sync from Figma," "does Figma match my code," "my Figma and code have drifted apart," "generate Figma docs pages from my specs," or any request involving Figma variables, variant sets, component properties, or bound variables alongside a codebase. Works for greenfield and retrofit, Tailwind and plain CSS — detect which

0 Updated 2 weeks ago
ejun-9