How to Use GSD Spike and Sketch Commands for Throwaway Experiments Before Planning

Apr 21, 2026

I often find myself hesitating before starting a complex feature. Questions like “Is this technically feasible?” or “What UI layout would work best?” slow me down. I recently discovered that GSD (Get Shit Done) has two commands designed exactly for these moments: /gsd-spike and /gsd-sketch.

When to Spike vs Sketch

Before diving into planning, I ask myself what kind of uncertainty I’m facing:

Technical feasibility — Can this library integrate with our stack? Which approach will work? → Use /gsd-spike
UI/UX design — What layout suits this dashboard? How should mobile navigation behave? → Use /gsd-sketch

Both commands run without requiring a full project initialization. They’re designed for throwaway experiments that validate assumptions before I commit to detailed planning.

The Spike Workflow

When I need to validate a technical approach, I run:

/gsd-spike "Can we integrate Stripe webhooks with our event sourcing system?"

GSD responds by running 2-5 focused experiments. Each experiment follows a Given/When/Then structure:

Experiment 1: Stripe webhook parsing
Given: A Stripe webhook payload arrives
When: Our event handler processes it
Then: The event is stored in our event store
Verdict: PASS

Experiment 2: Idempotency handling
Given: The same webhook arrives twice
When: Our system processes it
Then: Only one event is recorded
Verdict: INCONCLUSIVE

All artifacts get stored in .planning/spikes/. I can review the experiments, see which approaches passed or failed, and understand why.

Quick Spikes

When I want faster validation with fewer experiments:

/gsd-spike "Test Redis vs Memcached for session storage" --quick

The --quick flag reduces the number of experiments, giving me a faster (though less thorough) exploration.

Spike Wrap-Up

After running spikes, I package the findings:

/gsd-spike-wrap-up

This command creates a project-local skill that captures what worked, what failed, and the recommended approach. Future planning and execution conversations automatically load this context.

The Sketch Workflow

For UI exploration, I use sketching instead:

/gsd-sketch "Dashboard layout for real-time analytics"

GSD produces 2-3 HTML mockup variants. These aren’t static screenshots—they’re interactive mockups where I can click around and see hover states.

Variant A: Dense data table with sidebar filters
- Pros: Maximum information density
- Cons: May overwhelm new users

Variant B: Card-based summary with expandable details
- Pros: Cleaner initial view
- Cons: More clicks to see full data

Variant C: Split view with chart + table
- Pros: Visual + data in one screen
- Cons: Less space for either

Artifacts live in .planning/sketches/. I can open the HTML files in a browser and interact with each variant.

Quick Sketches

Same as spikes, the --quick flag speeds things up:

/gsd-sketch "Mobile navigation for settings page" --quick

Sketch Wrap-Up

When I’ve decided on a design direction:

/gsd-sketch-wrap-up

This packages my design decisions into a skill that future /gsd-ui-phase conversations can reference.

Real Example: Pre-Planning Validation

Last week I needed to add a file upload feature. I was uncertain about the technical approach and the UI design.

First, I validated the technical approach:

/gsd-spike "Handle large file uploads with progress tracking"

The experiments revealed that direct-to-S3 uploads with presigned URLs would work better than server-proxy uploads. One experiment showed server-proxy uploads would timeout for files over 50MB.

Then I explored the UI:

/gsd-sketch "File upload interface with drag-drop and progress indicators"

I got three interactive variants. After clicking through them, I favored the card-based upload zone with inline progress bars.

Summary

In this post, I covered how to use GSD’s spike and sketch commands for pre-planning validation. /gsd-spike runs technical feasibility experiments with Given/When/Then verdicts, while /gsd-sketch produces interactive HTML mockup variants. Both store artifacts in .planning/ and offer wrap-up commands that package findings into project-local skills. The --quick flag speeds up exploration when I need faster answers. These commands help me validate assumptions before committing to full planning, reducing the risk of discovering problems mid-implementation.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!