Quick Design

Quick Design:

Lightweight Design Specs for Small Game Changes

What Is This?

Quick Design is a specialized skill for the Happycapy Skills platform, designed to streamline the creation of concise design specifications for minor changes in a game development environment. Unlike a full Game Design Document (GDD), which is intended for large systems or entirely new features, Quick Design is purpose-built for small-scale adjustments that are too significant to be implemented without documentation, but not substantial enough to require the overhead of a complete GDD process. The Quick Design skill enables rapid specification, review, and embedding of design intent directly into story or code files, ensuring that even the smallest tweaks are traceable and justified.

This skill is especially useful in collaborative environments where multiple contributors may need to understand the rationale behind small modifications, such as tuning variables, minor mechanic updates, or balance tweaks. All Quick Design specs are output as Markdown files in the design/quick-specs/ directory, following a standardized naming convention, for easy reference and version control.

Why Use It?

Traditional GDD workflows can be too heavy for rapid iteration or minor feature adjustments. Quick Design fills the gap by providing a documented, lightweight path for changes that:

• Do not warrant the overhead of full documentation
• Need to be executed and reviewed quickly (typically under four hours of implementation)
• Still require written rationale for decision tracking, team alignment, or future reference

By using Quick Design, teams avoid the pitfalls of undocumented changes, such as lost context, unclear intent, or accidental regressions. The skill is particularly valuable in fast-paced prototyping, live-operation balancing, and incremental improvements to established systems.

How to Use It

To invoke the Quick Design skill, provide a brief description of the intended change. The skill will guide you through classifying, specifying, and documenting the change in an efficient and structured format. The process involves:

1. Classify the Change:
   Read your argument and categorize the change as one of the following:

   • Tuning: Adjusting numerical or balance values without altering behavior.
   • Tweak: Making a small behavioral change with no new states or branches.
   • Small Addition: Introducing a minor feature to an existing system.
   • Standalone Minor Feature: Adding a simple, isolated feature too small for the full GDD.

2. Fill Out the Quick Design Spec:
   The skill will prompt for required fields, such as:

   • Summary: One-sentence description of the change.
   • Rationale: Why the change is needed.
   • Current Behavior: How the system works now.
   • Proposed Change: What will be different.
   • Implementation Notes: Any technical or design considerations.
   • Test Criteria: How to verify the change is correct.

3. Output the Spec:
   The completed spec is saved as a Markdown file in the design/quick-specs/ directory, named as [name]-[date].md. This file can be referenced in pull requests or linked from story/task tracking tools.

Example Usage:
Suppose you want to increase the player’s dash speed from 8 to 10 units per second.

Invocation:

/quick-design "Increase player dash speed from 8 to 10 units per second"

Generated Spec Example:

## Quick Design Spec:

Increase Player Dash Speed

- **Summary:** Increase player dash speed from 8 to 10 units per second.
- **Rationale:** Improves game pace and makes movement feel more responsive.
- **Current Behavior:** Player dash speed is set to 8 units/sec in PlayerController.
- **Proposed Change:** Set dash speed to 10 units/sec.
- **Implementation Notes:** Update `PlayerController.cs`, line 115.
- **Test Criteria:** Player dashes noticeably faster. Speed value confirmed in debug logs. No animation glitches observed.

When to Use It

Use Quick Design whenever you encounter a change that:

• Requires less than four hours to implement
• Is too minor for the /design-system full GDD process
• Needs to be tracked for review, future reference, or team communication

Common scenarios include:

• Balance adjustments (e.g., health values, cooldown timers)
• Minor mechanics tweaks (e.g., invincibility frames, jump height)
• Small feature additions (e.g., sound on action, UI notification)
• Standalone features with limited scope and no system-wide impact

Do not use Quick Design for:

• Large system overhauls
• Features with complex branching or dependencies
• Changes requiring stakeholder review, broad documentation, or major workflow updates

Important Notes

• Traceability: Every Quick Design spec is a permanent artifact, improving project traceability.
• Integration: Specs should be referenced in code comments, pull requests, or user stories for clear linkage between intent and implementation.
• Review: Even small Quick Design specs should be reviewed by a peer or lead to ensure alignment and quality.
• Limitations: This skill is not a substitute for thorough documentation when major changes are involved. Use /design-system for anything outside the intended scope.

By using the Quick Design skill, teams can maintain agility without sacrificing clarity or accountability, ensuring that even the smallest changes are made with intention and transparency.