A collection of AI skills for implementing Spec Loops Driven Development (SLDD), a specs-driven feedback loop for AI-assisted development.
SLDD (Spec Loops Driven Development) is a methodology that adds engineering control around AI-assisted coding, enabling teams to maintain speed without sacrificing quality. This repository contains ready-to-use skills that implement the SLDD process.
This work is based on the article "Vibe Coding, But Production-Ready: A Specs-Driven Feedback Loop for AI-Assisted Development" by Loiane Groner.
The goal is not to stop vibe coding. The goal is to add engineering control around vibe coding so we can keep speed without sacrificing quality.
— Loiane Groner
When using AI for code generation, teams often face:
- Version drift: AI selects framework versions that don't align with team policy
- Missing non-functional requirements: Security, observability, maintainability
- Diluted product intent: Implementation starts before design is clear
- Architecture confusion: Plausible codebase mistaken for valid architecture
SLDD provides a structured feedback loop that prevents these issues while maintaining development velocity.
Install all SLDD skills with a single command:
npx skills add soujava/sldd-skillsThis will automatically download and configure all SLDD skills for your AI agent.
Copy the skill directories to your Claude skills folder:
# Clone the repository
git clone https://github.com/soujava/sldd-skills.git
# Copy to Claude skills directory
cp -r sldd-skills/skills/sldd-* ~/.claude/skills/Copy the skill directories to your OpenCode skills folder:
# Clone the repository
git clone https://github.com/soujava/sldd-skills.git
# Copy to OpenCode skills directory
cp -r sldd-skills/skills/sldd-* ~/.agents/skills/These skills are plain Markdown files with YAML frontmatter. They can be adapted to any AI tool that supports:
- System prompts or instructions
- Reusable prompt templates
- Agent/skill workflows
Run one skill at a time. Review and approve the output before moving to the next step.
┌─────────────────────────────────────────────────────────────────┐
│ SLDD Process Flow │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Start: sldd-00-process-overview-and-navigation-guide │
│ Understand the process, choose the right skill │
│ │
│ ▼ │
│ Step 01: sldd-01-product-intent-specification │
│ Define problem, users, metrics, risks │
│ │
│ ▼ │
│ [Optional] sldd-99: Existing Codebase Understanding │
│ (Required for existing codebases, skip for greenfield) │
│ │
│ ▼ │
│ Step 02: sldd-02-high-level-technical-design │
│ Architecture, system boundaries, data flow │
│ │
│ ▼ │
│ Step 03: sldd-03-low-level-design-and-version-policy │
│ API contracts, data models, version policy │
│ │
│ ▼ │
│ ─ ─ ─ ─ ─ ─ GATE: Design Review ─ ─ ─ ─ ─ ─ │
│ │
│ ▼ │
│ Step 04: sldd-04-tests-first-driven-by-acceptance-criteria │
│ Write tests only (TDD), no production code │
│ │
│ ▼ │
│ Step 05: sldd-05-minimal-implementation-to-pass-tests │
│ Minimal code to make tests pass │
│ │
│ ▼ │
│ Step 06: sldd-06-verification-and-feedback-report │
│ Audit implementation, go/no-go decision │
│ │
│ ▼ │
│ Production Ready ✓ │
│ │
└─────────────────────────────────────────────────────────────────┘
No implementation prompts (steps 04-05) before intent and design (steps 01-03) are reviewed and approved.
If a gap appears at any step, loop back to the earlier step and revise.
| Step | Skill | Description |
|---|---|---|
| 00 | sldd-00-process-overview-and-navigation-guide |
Navigate the SLDD process and choose the correct skill |
| 01 | sldd-01-product-intent-specification |
Define problem, users, metrics, risks, acceptance criteria |
| 02 | sldd-02-high-level-technical-design |
Architecture diagram, component responsibilities, data flow |
| 03 | sldd-03-low-level-design-and-version-policy |
API contracts, data models, error handling, version policy |
| 04 | sldd-04-tests-first-driven-by-acceptance-criteria |
Write tests first in strict TDD mode |
| 05 | sldd-05-minimal-implementation-to-pass-existing-tests |
Minimal code to make tests pass |
| 06 | sldd-06-verification-and-feedback-report |
Audit implementation, compliance matrix, go/no-go decision |
| 99 | sldd-99-existing-codebase-understanding-and-context-summary |
Read and summarize existing codebase (optional prerequisite) |
- Begin with
sldd-00-process-overview-and-navigation-guideto understand the process - Run
sldd-01-product-intent-specificationto define product intent - For existing codebases: run
sldd-99-existing-codebase-understanding-and-context-summary - Follow steps 02-06 in sequence
- Review and approve each step before proceeding
After completing sldd-01 (product intent), run sldd-99-existing-codebase-understanding-and-context-summary to ground design decisions in current architecture before proceeding to sldd-02.
Skip sldd-99 and proceed directly from sldd-01 to sldd-02.
When using an AI tool that supports skills:
/sldd-01-product-intent-specification
Feature idea: Build a user authentication system with email/password and OAuth providers (Google, GitHub)
The skill will guide the AI to produce a structured product intent specification.
- Vibe coding: Excellent for discovery and fast prototypes
- Specs-driven: Essential for production decisions
- The winning model: Both, in sequence
| Context | Approach |
|---|---|
| Early discovery | Vibe coding first |
| User-facing in production | Specs-driven loop first |
| Migration or platform work | Include explicit version checks |
The role shifts from writing every line to orchestrating and validating:
- Define intent and constraints
- Review architecture decisions
- Verify correctness
- Own what gets committed
Tests are written before implementation:
- Unit tests for logic
- Integration tests for data boundaries
- E2E tests for user-visible flows
| Before SLDD | After SLDD |
|---|---|
| Version drift discovered late | Version policy enforced upfront |
| Missing non-functional requirements | Security, observability designed in |
| Scope creep from unclear acceptance criteria | Explicit Given/When/Then criteria |
| Expensive rework after release | Gaps caught during design |
| Unreliable estimates | Structured decomposition enables accurate estimates |
A lightweight process to adopt:
- No implementation prompts before intent + design are approved
- Every AI-generated project includes a version validation step
- Architecture changes during coding require a design delta note
- PRs include a spec compliance checklist
- Release readiness requires explicit support-lifecycle verification
- Claude Code - Custom Instructions
- OpenCode - Skills System
- Cursor - Rules for AI
- GitHub Copilot - Custom Instructions
The SLDD methodology and original article content are by Loiane Groner, licensed under CC BY 4.0.
This skills implementation is provided for community use.
Contributions are welcome! Please feel free to submit issues or pull requests to improve the skills, add examples, or enhance documentation.
- Loiane Groner for creating and sharing the SLDD methodology
- The broader AI-assisted development community for advancing responsible AI coding practices
