Skip to main content
Quick mode is GSD’s fast path for small, ad-hoc tasks that don’t need full milestone ceremony. You get the same atomic commits and state tracking, but skip research, discussion, and verification agents.

​
When to Use Quick Mode

Use /gsd:quick for tasks that are clear, small, and urgent. Use full workflow for anything that requires research, has ambiguity, or is part of a larger milestone.

​
Perfect for quick mode:

  • Bug fixes
  • Small feature additions
  • Configuration changes
  • Refactoring isolated code
  • One-off maintenance tasks
  • Urgent hotfixes

​
Use full workflow for:

  • Features that need research
  • Complex multi-file changes
  • Work with unclear requirements
  • Anything tied to milestone requirements
  • Tasks requiring architectural decisions

​
How It Works

Quick mode is the same system with a shorter path:
1

Describe the task

Tell GSD what you want to do. Be specific.
2

Planning (quick mode)

Spawns gsd-planner in quick mode - creates a single atomic plan without research or verification.
3

Execution

Spawns gsd-executor with fresh 200K context to implement the plan.
4

Atomic commit

Work is committed immediately with structured commit message.
5

State tracking

Updates STATE.md “Quick Tasks Completed” table (NOT ROADMAP.md).

​
Usage

​
Basic quick mode

/gsd:quick
You’ll be prompted to describe what you want to do. The system skips research, plan-checking, and verification.

​
Quick mode with discussion

/gsd:quick --discuss
Adds a lightweight discussion phase before planning. Use when:
  • The task has some ambiguity
  • You want to surface assumptions upfront
  • Gray areas are worth resolving before coding
The discussion creates a CONTEXT.md file that feeds into planning, ensuring Claude understands your preferences.

​
Full quick mode

/gsd:quick --full
Enables plan-checking (max 2 iterations) and post-execution verification. Use when:
  • You want quality guarantees
  • The task is important but doesn’t justify full milestone ceremony
  • You’re working in an unfamiliar area

​
Combined flags

/gsd:quick --discuss --full
Gives you discussion + plan-checking + verification. This is close to a regular phase but tracked separately.

​
Comparison: Quick vs Full Workflow

/gsd:quick
> "Add dark mode toggle to settings"
Flow:
  1. Task description
  2. Planning (no research)
  3. Execution
  4. Commit
  5. State update
Time: 5-10 minutesAgents spawned: 2 (planner, executor)Output: .planning/quick/001-add-dark-mode-toggle/

​
What Quick Mode Skips

StageRegular PhaseQuick Mode
Discussiongsd-discusserSkipped (unless --discuss)
Research4 parallel researchersSkipped
Plan checkinggsd-plan-checker loopsSkipped (unless --full)
Verificationgsd-verifier checks goalsSkipped (unless --full)
UAT/gsd:verify-workSkipped

​
What Quick Mode Keeps

Quick mode preserves all GSD guarantees that matter for correctness and traceability.
  • Atomic commits - Each task gets its own commit immediately
  • State tracking - STATE.md is updated with completion
  • Fresh context - Executor gets clean 200K window
  • Structured plans - Uses same XML plan format
  • Same agents - Planner and executor are identical to full workflow

​
Directory Structure

Quick tasks live in .planning/quick/, separate from phases: 
.planning/
  quick/
    001-add-dark-mode-toggle/
      PLAN.md
      SUMMARY.md
    002-fix-login-button/
      PLAN.md
      SUMMARY.md
  phases/
    01-user-authentication/
      01-01-PLAN.md
      01-01-SUMMARY.md
This separation keeps quick fixes from polluting your roadmap while still tracking them.

​
State Tracking

Quick tasks update a separate table in STATE.md: 
## Quick Tasks Completed

| ID | Description | Date |
|----|-------------|------|
| 001 | Add dark mode toggle | 2024-03-15 |
| 002 | Fix login button mobile issue | 2024-03-15 |
This gives you history without cluttering ROADMAP.md.

​
Example Usage

/gsd:quick
> "Fix the login button not responding on mobile Safari"

# Creates:
# .planning/quick/001-fix-login-button/PLAN.md
# .planning/quick/001-fix-login-button/SUMMARY.md
# Git commit: "fix(quick-001): login button mobile safari issue"

​
Deciding: Quick vs Full

Ask yourself:
  • I know exactly what needs to be done
  • It touches 1-3 files
  • No research is needed
  • It’s not tied to roadmap requirements
  • I need it done in under 10 minutes
  • It’s a fix, config, or small addition

​
Best Practices

​
Do:

  • Use quick mode for truly quick tasks
  • Add --full flag when quality matters
  • Use --discuss when there’s any ambiguity
  • Keep quick task descriptions specific and actionable

​
Don’t:

  • Use quick mode for milestone work (plan it properly)
  • String multiple quick tasks together (consider a phase instead)
  • Skip full workflow to save time on complex tasks (you’ll pay later)

​
Integration with Milestones

Quick tasks are independent of your roadmap: 
# You're in the middle of Phase 5
/gsd:progress
> Current phase: 5/12
> Next: /gsd:execute-phase 5

# But something urgent comes up
/gsd:quick
> "Fix production error in user export"

# Done. Now back to roadmap.
/gsd:execute-phase 5
Quick mode doesn’t interrupt your milestone flow - it’s a side channel for urgent work.

​
When Quick Mode Goes Wrong

If you find yourself:
  • Running 5+ quick tasks in a row
  • Rewriting quick task output repeatedly
  • Wishing you had research or verification
You probably need a proper phase: 
# Instead of this:
/gsd:quick  # attempt 1
/gsd:quick  # attempt 2
/gsd:quick  # attempt 3

# Do this:
/gsd:add-phase "Fix user export issues"
/gsd:discuss-phase 13
/gsd:plan-phase 13
/gsd:execute-phase 13
Quick mode is powerful but not magic. Complex work deserves full workflow planning, research, and verification.