| name | using-gdd |
| description | Use when starting any GDD session - establishes how to find and apply GDD skills. |
| disable-model-invocation | true |
Using GDD
This is the bootstrap discipline contract for every Get Design Done session. Read it
first; it tells you how to find and apply the right GDD skill before you act.
The 1% rule
If you think there is even a 1% chance a skill might apply, you ABSOLUTELY MUST invoke the skill.
In GDD, almost every request maps to a pipeline stage - brief, explore, plan, design,
verify - or to a cross-cutting skill (discuss, audit, style, darkmode). When in doubt,
search for and read the skill's body. The cost of reading a skill is trivial; the cost of
free-handing a stage is rework, scope creep, and a broken pipeline state.
Red flags - Thought → Reality
When you catch yourself thinking any of the following, STOP and check for a skill.
| Thought | Reality |
|---|
| This is just a simple design question. | Questions are tasks. Check for a skill. |
| I'll just tweak the CSS directly. | Token changes go through the pipeline - check /gdd:design. |
| I already know the codebase, skip explore. | Explore probes connections you haven't re-checked this cycle. |
| This change is too small to plan. | Plan-skipped tasks blow scope per cycle telemetry. Run /gdd:plan. |
| I can write the brief later. | No brief means no shared problem statement - /gdd:brief comes first. |
| The user clearly wants X, I'll skip discuss. | Ambiguity hides here. /gdd:discuss surfaces the real constraint. |
| I'll verify by eyeballing it. | Verification is a stage with criteria - run /gdd:verify, don't guess. |
| It's obviously a dark-mode tweak. | Color-scheme work has its own skill - check /gdd:darkmode. |
| Let me just compare these two designs quickly. | Comparison is an audit task - /gdd:compare has the rubric. |
| This is a one-off, no skill needed. | "One-off" is the most common rationalization in the telemetry. Check anyway. |
| I'll refactor the style tokens by hand. | /gdd:style owns token edits so the pipeline stays consistent. |
| The audit can wait until after I ship. | An un-audited cycle is an unverified cycle - /gdd:audit before close. |
Skill priority order
When more than one skill could apply, resolve in this order:
- Process - brief / explore / discuss. Establish the problem and context first.
- Implementation - design / style / darkmode. Only after process is settled.
- Audit - verify / compare / audit. Close the loop before declaring done.
Never run an Implementation skill before the Process skills that gate it have produced
their artifact. Never declare a cycle complete without an Audit skill.
Instruction priority
When instructions conflict, obey this precedence (highest first):
- The user's CLAUDE.md - project- and user-level directives always win.
- GDD skills - the skill body is the source of truth for how a stage runs.
- Defaults - your own general training and habits come last.
If a GDD skill contradicts the user's CLAUDE.md, the CLAUDE.md wins and you flag the
conflict. If your instinct contradicts a GDD skill, the skill wins.
GDD pipeline flow
The core flow is Brief → Explore → Plan → Design → Verify, with branch points:
- Brief captures the problem (
/gdd:brief). Branch: a rough idea can sketch or spike
off the brief before exploration; a changed problem loops back via --re-brief.
- Explore scans the codebase and connections (
/gdd:explore) - even on a familiar
repo, because connections drift each cycle.
- Plan decomposes work into tasks (
/gdd:plan). Skipping it is the top cause of scope
blow-up; small tasks still get a plan.
- Design implements (
/gdd:design, with /gdd:style and /gdd:darkmode as
implementation peers). Implementation never runs ahead of an approved plan.
- Verify checks against criteria (
/gdd:verify), then /gdd:audit / /gdd:compare
close the loop. On pass the cycle completes; on fail it loops back to the failing stage.
/gdd:discuss runs alongside any stage to resolve ambiguity before it propagates.
