So you've been vibe coding for a while. The honeymoon phase is over. You've noticed the pattern: you write a prompt, AI generates something close-ish, you iterate 47 times, and somewhere around hour three you're questioning your life choices.
Here's the thing nobody tells you: the problem isn't your prompts. It's that you're asking AI to read your mind.
Key Takeaways:
- Spec-driven development (SDD) front-loads the thinking, so AI builds what you actually want
- GitHub Spec Kit works with Claude Code, GitHub Copilot, Gemini CLI, and 10+ other agents
- The
/specify → /plan → /tasks → /implementworkflow cuts iteration cycles by 60-70%- Frontend-specific specs need component boundaries, state requirements, and styling constraints
In This Article
- What is Spec-Driven Development?
- GitHub Spec Kit Setup (5 Minutes)
- The 4-Step Frontend Workflow
- Real Example: Dashboard Component Spec
- Frontend-Specific Tips
- FAQ
What is Spec-Driven Development?
Traditional vibe coding: prompt → code → fix → fix → fix → ship (maybe).
Spec-driven development: spec → plan → implement → ship.
The difference? You're not hoping AI understands what you mean. You're telling it exactly what you need, upfront, in a structured document that becomes the source of truth.
GitHub released Spec Kit in late 2025 as an open-source toolkit that makes this process dead simple. It integrates with Claude Code, GitHub Copilot, Gemini CLI, Cursor, Windsurf—basically anything you're already using.
The core philosophy is simple: specs don't serve code. Code serves specs.
If you've ever written a proper spec for AI coding, you know how much better the output gets. Spec Kit just formalizes that process with guardrails.
GitHub Spec Kit Setup (5 Minutes)
You need Python 3.11+ and the uv package manager. If you've got those, installation is one command:
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
Initialize a project:
specify init my-dashboard --ai claude
That's it. Spec Kit creates a .speckit folder with config files and makes slash commands available in your AI agent.
| Supported Agent | Slash Commands |
|---|---|
| Claude Code | Full support |
| GitHub Copilot | Full support |
| Gemini CLI | Full support |
| Cursor | Full support |
| Windsurf | Full support |
Pick your agent during init, and Spec Kit configures itself automatically.
The 4-Step Frontend Workflow
This is where spec-driven development gets practical. Here's the GitHub Spec Kit frontend tutorial workflow I use for every component:
Step 1: Specify (/speckit.specify)
Describe what you want. Not how—what. User stories, acceptance criteria, constraints.
For frontend, this means:
- What does the user see?
- What can they interact with?
- What states exist (loading, error, empty)?
- What are the styling constraints?
Example prompt:
/speckit.specify Dashboard overview component for a SaaS analytics app. - Shows 4 KPI cards in a responsive grid - Each card displays: metric name, current value, % change, trend icon - Cards have hover state with subtle elevation - Mobile: 2x2 grid. Desktop: 1x4 row - Uses existing design tokens from /styles/tokens.css - Loading state: skeleton placeholders - Error state: retry button per card
Step 2: Plan (/speckit.plan)
The AI proposes a technical plan based on your spec. This is where you catch architectural issues before writing any code.
/speckit.plan
Spec Kit generates:
- Component breakdown
- State management approach
- Data flow
- File structure
This is the step most people skip. Don't. Catching a bad architectural decision here saves hours later.
Step 3: Tasks (/speckit.tasks)
Break the plan into small, reviewable units.
/speckit.tasks
You'll get something like:
- Create KPICard component with props interface
- Implement responsive grid container
- Add loading skeleton variant
- Add error state with retry logic
- Connect to data source
- Write unit tests
Each task is scoped enough that if something breaks, you know exactly where.
Step 4: Implement (/speckit.implement)
Now the AI executes. But here's the key difference: it's not guessing. It's following a validated spec and plan.
/speckit.implement
The implementation stays aligned with your spec because every decision references back to it.
Real Example: Dashboard Component Spec
Let me show you a spec-driven development frontend example that actually works.
Here's a spec I used for a user activity dashboard:
## Component: UserActivityFeed ### User Story As a product manager, I want to see recent user activity so I can understand engagement patterns. ### Requirements - Display last 20 activity items in a scrollable list - Each item shows: user avatar, action description, timestamp (relative) - Group items by date (Today, Yesterday, This Week, Older) - Real-time updates via WebSocket (if connected) - Fallback to polling every 30s if WebSocket unavailable ### UI States 1. **Loading**: Skeleton list with 5 placeholder items 2. **Empty**: Illustration + "No activity yet" message 3. **Error**: "Failed to load" + retry button 4. **Loaded**: Activity list with infinite scroll ### Constraints - Use shadcn/ui components - Tailwind for styling, no custom CSS - Maximum 3 re-renders on new data - Must work in <800px viewport ### Acceptance Criteria - [ ] Loads initial data in <500ms - [ ] Smooth scroll performance (60fps) - [ ] Accessible: keyboard navigation, screen reader labels - [ ] Mobile-responsive without horizontal scroll
That spec took 10 minutes to write. It saved me 2 hours of iteration.
When I ran /speckit.implement, the AI generated exactly what I specified—including the edge cases I'd have forgotten to mention in a normal prompt.
Want to try this yourself?
Frontend-Specific Tips
Here's what I've learned writing specs for AI coding on frontend projects:
1. Always specify component boundaries
Vague: "Build a settings page" Better: "Build a SettingsPage that contains: ProfileSection, NotificationPrefs, BillingInfo. Each section is a separate component with its own loading state."
2. Include state requirements explicitly
AI tends to over-engineer or under-engineer state. Tell it exactly what you need:
- Local state (useState)
- Server state (React Query)
- Global state (Zustand)
I wrote a whole guide on AI state management prompts if you want to go deeper.
3. Reference existing files
Spec Kit lets you point to existing code:
Use the same styling pattern as /components/ui/Card.tsx Follow the data fetching pattern from /hooks/useUsers.ts
This is context engineering at its best—giving AI the right reference points.
4. Define responsive breakpoints in the spec
Don't assume AI knows your breakpoints. Specify:
- Mobile: <768px
- Tablet: 768-1024px
- Desktop: >1024px
5. Use the clarify command
If Spec Kit flags something ambiguous, use /speckit.clarify before proceeding. Better to answer a question now than debug a misunderstanding later.
When to Use Specs vs Quick Prompts
Spec-driven development isn't for everything.
| Use Spec Kit | Use Quick Prompts |
|---|---|
| Multi-component features | Single utility functions |
| Complex state management | Simple static components |
| Team collaboration | Solo prototyping |
| Production code | Throwaway experiments |
For quick UI iterations, sometimes you just need to vibe. That's fine. But anything that'll live in production for more than a week? Spec it.
Frequently Asked Questions
What is GitHub Spec Kit?
GitHub Spec Kit is an open-source toolkit for spec-driven development. It provides a structured workflow where you define specifications before generating code, using slash commands that work with Claude Code, GitHub Copilot, Gemini CLI, and other AI coding assistants.
How do I use Spec Kit for frontend development?
Install with uv tool install specify-cli, initialize with specify init project-name --ai claude, then follow the four-step workflow: /speckit.specify for requirements, /speckit.plan for architecture, /speckit.tasks for task breakdown, and /speckit.implement for code generation.
Is spec-driven development worth it for small projects?
For quick prototypes, probably not—the overhead isn't worth it. But for any frontend component that needs multiple states, responsive design, or will be maintained long-term, specs pay for themselves in reduced iteration time.
Does Spec Kit work with my existing AI coding tool?
Spec Kit supports 16+ AI agents including Claude Code, GitHub Copilot, Cursor, Windsurf, Gemini CLI, and more. Run specify init --ai to see the full list during setup.
You Might Also Like
- AI Coding Spec Template That Actually Ships - Manual spec writing before you need the full Spec Kit workflow
- Context Engineering for AI Coding - Master the skill that makes specs (and prompts) actually work
- Prompt Chaining for UI: Build Complex Pages - Multi-step workflows for when you're not using Spec Kit
Try Spec-Driven Development Today
Look, I get it. Writing specs feels like extra work. But here's the uncomfortable truth: you're already doing the work—just at the wrong time. Every iteration cycle, every "that's not what I meant," every 3am debugging session is spec work you're doing after the fact.
GitHub Spec Kit just moves that work to the beginning, where it belongs.
Start with one component. Write the spec. Run the workflow. See if your iteration count drops.
I'm betting it will.
Written by the Fardino Team. We build AI tools for frontend developers. Try Fardino free →
