DEV Community

我妻良樹
我妻良樹

Posted on

How I Implemented 71 Files with Zero Rework Using cc-sdd

Key Takeaways

I tried cc-sdd (Claude Code Spec-Driven Development) for the first time.

GitHub logo gotalab / cc-sdd

Spec-driven development (SDD) for your team's workflow. Kiro style commands that enforce structured requirements→design→tasks workflow and steering, transforming how you build with AI. Support Claude Code, Codex, Cursor, Github Copilot, Gemini CLI and Windsurf.

cc-sdd: Spec-driven development for your team's workflow

npm version install size license: MIT

Transform AI coding agents into production-ready spec-driven development

One command. Hours instead of weeks. Requirements → Design → Tasks → Implementation.

👻 Kiro-inspired — Similar Spec-Driven, AI-DLC style as Kiro IDE, so existing Kiro specs remain compatible and portable.

Stop losing 70% of development time to meetings, documentation ceremonies, and scattered context. cc-sdd brings structured AI-DLC (AI-Driven Development Lifecycle) and Spec-Driven Development to Claude Code, Cursor, Gemini CLI, Codex CLI, GitHub Copilot, Qwen Code, and Windsurf.

What you get:

  • Spec-first guarantees — Approve requirements/design upfront, then AI implements exactly as specified
  • Parallel execution ready — Tasks decomposed for concurrent implementation with dependency tracking
  • Team-aligned templates — Customize once, all agents output docs that fit your approval process
  • Project Memory — AI remembers your architecture, patterns, and standards across sessions
  • 7 agents, unified workflow

The bottom line: I was able to deliver high-quality implementation with virtually no rework. For this user management feature implementation, the changes spanned 71 files (about 30 of which were specification Markdown documents), and ultimately there were almost no major setbacks.

The defining characteristic of cc-sdd is that you follow a predetermined sequence. You progress through requirements → design → task breakdown, with humans deeply involved in refining each phase before implementation. Once the content is finalized, the tool determines the execution order, and you simply follow along with implementation tasks.

What I found particularly valuable was discovering gaps during the initial requirements phase. When generating EARS-format requirements, I had several "oh, I didn't consider this condition" moments.
Additionally, it precisely draws the line on scope—clearly stating what won't be developed this time (e.g., two-factor authentication, user profile image management, etc.) and considering both the current scope and future development items. I found this really helpful.

On the other hand, compared to vibe-coding (the style of trial-and-error development), cc-sdd isn't a try-and-error approach, so it's not ideal for building while testing. It's best suited for tackling large chunks of work, while small iterative changes have a different flavor.

Also, it does take time for review and approval. Each phase requires confirming and approving generated documents. However, with practice, there seem to be many optimization opportunities—potentially reaching a point where you can hand off everything after requirements and design are approved. I want to get more comfortable with this going forward.

Technology Stack

  • cc-sdd v2.x (kiro commands)
  • Claude Code - AI pair programming tool
  • Next.js 15 (App Router) + TypeScript
  • Prisma ORM + PostgreSQL RLS
  • NextAuth.js 4.x - Authentication
  • shadcn/ui + Radix UI - UI components
  • Zod - Validation

What is cc-sdd?

cc-sdd (Claude Code Spec-Driven Development) enables spec-driven development using AI coding agents. Unlike the traditional "write working code first, then adjust" approach, it follows a requirements → design → task breakdown → implementation sequence.

/kiro:spec-init
→ /kiro:spec-requirements
→ /kiro:spec-design
→ /kiro:spec-tasks
→ /kiro:spec-impl
Enter fullscreen mode Exit fullscreen mode

Key features:

  • Spec-first guarantee: Requirements and design approved before implementation
  • Parallel execution support: Track task dependencies while enabling concurrent execution
  • Team-unified templates: Custom templates shared across all agents
  • Project memory: Architecture and patterns remembered across sessions

Implementation Flow

Here's how the user management feature development progressed.

Phase 0: Setup

Started with cc-sdd installation.

npx cc-sdd@latest --claude --lang en
Enter fullscreen mode Exit fullscreen mode

Then executed /kiro:steering to set up project information, sharing the tech stack, directory structure, and coding conventions with the AI.

Phase 1: Requirements Definition

/kiro:spec-init user-management
/kiro:spec-requirements user-management
Enter fullscreen mode Exit fullscreen mode

This phase generated EARS (Easy Approach to Requirements Syntax) format requirements. Seven main requirements were defined:

  1. User Registration - Form validation, password complexity, success notification
  2. User List & Search - Pagination, search/filter/sort
  3. Role & Permission Management - ADMIN/OPERATOR/VIEWER, last admin protection
  4. User Edit & Delete - Info updates, soft delete, self-deletion prevention
  5. Session & Security - JWT, 7-day expiry
  6. Multi-tenant Isolation - Prisma RLS, automatic organizationId
  7. UI/UX & Accessibility - Responsive, toast notifications, keyboard nav

The key here was the requirements approval process. While reviewing generated requirements, I caught oversights like "prevent users from deleting themselves" and "prevent demoting the last admin."

Phase 2: Design

/kiro:spec-design user-management
Enter fullscreen mode Exit fullscreen mode

This command generated a 1,015-line detailed design document including:

  • System flows (Mermaid diagrams)
  • Component design
  • Data models (logical & physical)
  • Error handling strategy
  • Testing strategy
  • Security considerations

Thanks to the design doc, the architectural overview was crystal clear before entering implementation.

Phase 3: Task Breakdown

/kiro:spec-tasks user-management
Enter fullscreen mode Exit fullscreen mode

This generated an implementation plan with 6 main sections and 27 subtasks. Particularly useful:

  • Parallel-executable task identification: Phase 1 tasks 1.1, 1.2, 2.1 can run in parallel
  • Requirements traceability: Each task clearly maps to requirements
### Recommended Task Execution Order

#### Phase 1: Foundation Setup (Parallelizable)
- Tasks 1.1, 1.2, 2.1 can run in parallel

#### Phase 2: Backend Implementation (Parallelizable)
- Tasks 3.1, 3.2, 3.3, 3.4 can run in parallel (independent API interfaces)
Enter fullscreen mode Exit fullscreen mode

Phase 4: Implementation

/kiro:spec-impl user-management [task-numbers]
Enter fullscreen mode Exit fullscreen mode

During implementation, tasks were executed sequentially following dependencies. Each commit message includes which task was completed and which requirements were addressed.

feat: implement user validation schemas with comprehensive tests

Task 1.1 completed: Zod validation schema with password complexity

Requirements: 1.4, 1.6, 7.8
Enter fullscreen mode Exit fullscreen mode

cc-sdd vs Vibe-Coding Comparison

Aspect cc-sdd Vibe-Coding
Best for Large-scale, planned development Small-scale, exploratory development
Preparation Heavy (requirements → design → tasks) Light
Rework Minimal Tends to increase
Review overhead Required per phase Ad-hoc
Documentation Auto-generated Manual
Learning curve Moderate Low
Team adoption Easy (standardized) Tends toward individual styles

When to Choose Which

cc-sdd works well for:

  • New feature development (especially multi-file changes)
  • Team development (standardized process)
  • Features requiring future spec reference
  • Quality-focused production implementations

Vibe-coding works well for:

  • Prototyping & validation
  • Small bug fixes
  • Solo short-term development
  • Exploratory work with unclear specs

Considerations for Team Adoption

Benefits

  1. Quality standardization: Requirements → design → implementation order enforced
  2. Auto-generated documentation: Requirements, design docs, task lists remain as artifacts
  3. Efficient code reviews: Clear mapping between changes and requirements
  4. Improved onboarding: New members can understand features by reading specs

Considerations

  1. Learning curve: Understanding command systems and workflows required
  2. Increased review overhead: Time needed to confirm/approve outputs per phase
  3. Flexibility trade-off: Spec changes require design/task regeneration

Suggested Adoption Steps

  1. Individual trial: Try one feature personally (like this article)
  2. Team sharing: Share experience with team, gather feedback
  3. Template customization: Adjust for project-specific requirements
  4. Gradual rollout: Apply to new feature development, expand scope gradually

Lessons Learned

Unexpected Pitfalls

  • Managed DB service constraints can impact testing strategies
  • Parallel branch development leads to conflict resolution work
  • Beyond generated tasks, PR review feedback still needs addressing

Useful Insights for the Future

  • Hands-off after spec approval: Once design and task breakdown complete, implementation is relatively automated
  • Requirements traceability: Tracking which requirements each change addresses is valuable for auditing and documentation
  • Parallel task execution: Running independent tasks in parallel improves efficiency

Future Experiments

  • Template customization (reflecting project-specific patterns)
  • Multi-person parallel implementation (distributing tasks for concurrent progress)
  • Leveraging /kiro:validate-impl for implementation verification

Conclusion

cc-sdd shifts how we use AI coding tools from "just have it write something" to "progress consistently from requirements through design to implementation."

For this user management feature spanning 71 files, we maintained quality while minimizing rework. The biggest benefits were discovering gaps during the requirements phase and having generated documents available for future reference.

However, compared to vibe-coding, the preparation and review overhead increases, making it unsuitable for small changes. It's a tool that shines when "progressing large chunks systematically."

For those considering team adoption, I recommend starting with one feature personally. Based on that experience, you can determine if it fits your team's development style.


This article simplifies actual development experience. Project-specific information has been generalized.

Related Technologies: cc-sdd, Claude Code, Next.js 15, TypeScript, Prisma ORM, NextAuth.js, PostgreSQL RLS, Spec-Driven Development

References:

Author: 91works Development Team

Top comments (1)

Collapse
 
0x57origin profile image
0x57Origin

Awesome stuff!