Spec-Driven Development with Real Slash Commands

intermediate 15 min 📋 Copy-paste ready

Sources not yet verified

spec-drivenslash-commandsworkflowspec-kitkiro

Scenario

Context: You want to implement a new feature using spec-driven development instead of vibe coding

Goal: Learn the actual slash command syntax for spec-driven workflows across different AI tools

Anti-pattern: Jumping straight into coding without a specification

Tools: GitHub CopilotClaude CodeCursor

Conversation

What Are Spec-Driven Slash Commands?

Modern AI coding tools support slash commands that enforce a structured workflow: Requirements -> Design -> Tasks -> Implementation. This prevents 'vibe coding' where you just ask the AI to build something without clear specifications.

Available Command Systems:

• GitHub Spec Kit: /specify, /plan, /tasks
• cc-sdd (Kiro-style): /kiro:spec-init, /kiro:spec-requirements, /kiro:spec-design, /kiro:spec-tasks
• Claude Code custom: Create your own in .claude/commands/

👤 You

/specify

I need a notification system for our SaaS platform that supports email, SMS, and in-app notifications with user preferences and delivery scheduling.

The `/specify` command tells the AI to create a Product Requirements Document (PRD) focusing on 'what' and 'why', not technical implementation.

🤖 AI

Notification System - Product Requirements Document

Problem Statement

Users need timely, relevant notifications across multiple channels without being overwhelmed.

User Stories

1. As a user, I can choose which channels receive which notification types
2. As a user, I can set quiet hours when only critical notifications arrive
3. As an admin, I can see delivery success rates per channel

Functional Requirements

• FR-1: Support email, SMS, and in-app notification channels
• FR-2: User preference management (channel per notification type)
• FR-3: Scheduling: immediate, delayed, and recurring
• FR-4: Delivery status tracking (sent, delivered, failed, read)
• FR-5: Template management for consistent messaging

Non-Functional Requirements

• NFR-1: Deliver in-app notifications within 500ms
• NFR-2: Handle 10,000 notifications/minute at peak
• NFR-3: 99.9% delivery success rate for email/SMS

Out of Scope

• Push notifications (mobile app not launched yet)
• A/B testing of notification content
• Analytics dashboard (separate project)

Success Metrics

• Notification preference completion rate > 80%
• Unsubscribe rate < 2% per month

---

Spec created. Run /plan to define technical architecture.

The AI produces a complete PRD without technical decisions. Note the explicit 'Out of Scope' section - this prevents scope creep.

👤 You

/plan

Now we move from 'what' to 'how'. The `/plan` command generates technical architecture based on the specification.

🤖 AI

Notification System - Technical Plan

Architecture Overview

[Event Producer] -> [Message Queue] -> [Notification Service] -> [Channel Adapters]
                                              |
                                    [Preference Store] [Template Engine]

Technology Decisions

Component	Choice	Rationale
Message Queue	Redis Streams	Already in stack, supports delayed messages
Database	PostgreSQL	Existing, add preferences/templates tables
Email Provider	SendGrid	Current vendor, good deliverability
SMS Provider	Twilio	API simplicity, international support
In-App	WebSocket	Real-time requirement (500ms)

Data Contracts

interface NotificationEvent {
  id: string;
  userId: string;
  type: 'order_update' | 'security_alert' | 'marketing';
  channels: ('email' | 'sms' | 'in_app')[];
  payload: Record<string, unknown>;
  scheduledFor?: Date;
  priority: 'critical' | 'high' | 'normal' | 'low';
}

interface UserPreferences {
  userId: string;
  channels: {
    [notificationType: string]: ('email' | 'sms' | 'in_app')[];
  };
  quietHours?: { start: string; end: string; timezone: string };
}

Key Design Decisions

1. Queue-first: All notifications go through queue for reliability
2. Channel adapters: Each channel is pluggable (easy to add push later)
3. Preference lookup at send time: Allows real-time preference changes
4. Retry with backoff: Failed deliveries retry 3x with exponential backoff

---

Plan complete. Run /tasks to decompose into implementation tasks.

The plan stays grounded in the specification. Notice it doesn't add features - it implements exactly what was specified.

👤 You

/tasks

The `/tasks` command breaks the plan into ordered, implementable work items with dependencies.

🤖 AI

Implementation Tasks

Phase 1: Foundation (3 tasks)

TASK-001: Database Schema

• Create notification_preferences table
• Create notification_templates table
• Create notification_log table for delivery tracking
• Dependencies: None
• Files: migrations/20240115_notifications.sql

TASK-002: Event Types & Contracts

• Define TypeScript interfaces from plan
• Create Zod schemas for validation
• Dependencies: None
• Files: src/notifications/types.ts

TASK-003: Preference Service

• CRUD operations for user preferences
• Quiet hours evaluation logic
• Dependencies: TASK-001, TASK-002
• Files: src/notifications/preferences.service.ts

Phase 2: Core Pipeline (4 tasks)

TASK-004: Queue Integration

• Redis Streams producer/consumer setup
• Delayed message scheduling
• Dependencies: TASK-002
• Files: src/notifications/queue.ts

TASK-005: Template Engine

• Handlebars-based template rendering
• Variable substitution with type safety
• Dependencies: TASK-001
• Files: src/notifications/templates.service.ts

TASK-006: Channel Adapters

• Email adapter (SendGrid)
• SMS adapter (Twilio)
• In-app adapter (WebSocket broadcast)
• Dependencies: TASK-002
• Files: src/notifications/adapters/*.ts

TASK-007: Notification Dispatcher

• Main orchestrator: queue -> preferences -> template -> channel
• Retry logic with exponential backoff
• Dependencies: TASK-003, TASK-004, TASK-005, TASK-006
• Files: src/notifications/dispatcher.ts

Phase 3: API & Testing (2 tasks)

TASK-008: REST API Endpoints

• POST /notifications/send
• GET/PUT /users/:id/preferences
• GET /notifications/:id/status
• Dependencies: TASK-007
• Files: src/routes/notifications.ts

TASK-009: Integration Tests

• End-to-end notification flow
• Channel adapter mocks
• Preference filtering tests
• Dependencies: TASK-008
• Files: tests/notifications/*.test.ts

---

Tasks ready. Start with TASK-001 or ask me to implement a specific task.

Tasks are ordered by dependencies, have clear file locations, and form logical phases. This makes progress trackable.

---

Alternative: Kiro-Style Commands (cc-sdd)

If you're using the cc-sdd extension, the syntax is slightly different:

👤 You

/kiro:spec-init Photo albums with upload, tagging, and sharing

Kiro-style initialization creates a new spec file and sets up the workflow context.

🤖 AI

Created spec: photo-albums-en

Next steps:

1. /kiro:spec-requirements photo-albums-en - Generate EARS-format requirements
2. /kiro:spec-design photo-albums-en - Create architecture with Mermaid diagrams
3. /kiro:spec-tasks photo-albums-en - Decompose into implementation tasks

Or add -y flag to auto-approve each step:
/kiro:spec-requirements photo-albums-en -y

Kiro-style commands work with named specs, allowing you to manage multiple features simultaneously.

---

Creating Custom Commands in Claude Code

You can create your own spec commands by adding Markdown files to .claude/commands/:

mkdir -p .claude/commands

Create .claude/commands/specify.md:

Create a Product Requirements Document for the following feature.

Include:
- Problem statement
- User stories  
- Functional requirements (FR-1, FR-2, ...)
- Non-functional requirements
- Out of scope
- Success metrics

Do NOT include technical implementation details.

Feature: $ARGUMENTS

Now /project:specify Build a search feature will use your template.

Key Takeaways

• Use `/specify` first to document WHAT and WHY before any code
• Use `/plan` to establish technical architecture grounded in the spec
• Use `/tasks` to create ordered, dependency-tracked implementation steps
• Kiro-style commands (`/kiro:spec-*`) work across multiple AI tools
• Create custom commands in `.claude/commands/` for your team's workflow

Try It Yourself

Prompt Template

/specify

I need [YOUR FEATURE DESCRIPTION with key requirements and constraints]

Copy template

Variations to Try

• After /specify: Run `/plan` to get technical architecture
• After /plan: Run `/tasks` to get implementation breakdown
• For Kiro-style: `/kiro:spec-init [feature description]`
• Custom template: Create `.claude/commands/specify.md` with your team's PRD format

Related Content

📖 Structured Outputs & JSON Schema 📖 Context Windows 📖 Tokens & Tokenization 🏋️ prompt construction 🏋️ design schema

Sources

✓ GitHub: Slash Commands ⓘ

×

Spec-Driven Development with AI: Get Started with a New Open Source Toolkit

GitHub

GitHub Spec Kit formalizes the spec-driven development approach where detailed specifications precede AI code generation. The four-phase workflow (Specify → Plan → Tasks → Implement) ensures human oversight at each checkpoint. This is the antidote to 'vibe coding' - structured, auditable AI development. Key for assessing advanced workflow maturity.

Key Findings:

• Four-phase workflow: Specify, Plan, Tasks, Implement
• Specifications become executable artifacts
• Supports GitHub Copilot, Claude Code, Gemini CLI

Credibility: high

View Source ↗

✓ Anthropic: Custom Commands ⓘ

×

Claude Code: Best practices for agentic coding

Anthropic

Official best practices for Claude Code agentic development. Key for agentic_supervision dimension - demonstrates multi-file autonomous editing capabilities and supervision approaches.

Key Findings:

• Claude Code is a command line tool for agentic coding
• CLAUDE.md provides project-specific context and instructions
• Plan mode shows intentions before making changes

Credibility: high

View Source ↗