quick-design
SolidLightweight 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.
Install
Quality Score: 87/100
Skill Content
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
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
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.
spec
Create a spec (PRD) through user interview, codebase exploration, and module design. Use when starting a feature with unclear requirements, or asked to spec or define what to build, "write a spec", "write a PRD". Don't use when requirements are crisp and a plan exists (/plan, /build).