Spec-driven development separates PLANNING from IMPLEMENTATION. This skill defines how to create implementation specifications that enable reliable, predictable code generation.
npx claudepluginhub sumanpapanaboina1983/adlc-accelerator-kit-pluginsThis skill uses the workspace's default tool permissions.
Spec-driven development separates PLANNING from IMPLEMENTATION. This skill defines how to create implementation specifications that enable reliable, predictable code generation.
Creates structured specifications before coding for new projects, features, or changes with unclear requirements. Covers objectives, commands, project structure, code style, testing strategy, and boundaries.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Checks Next.js compilation errors using a running Turbopack dev server after code edits. Fixes actionable issues before reporting complete. Replaces `next build`.
Share bugs, ideas, or general feedback.
Spec-driven development separates PLANNING from IMPLEMENTATION. This skill defines how to create implementation specifications that enable reliable, predictable code generation.
# Implementation Specification
## Task Type
NEW_FEATURE | BUG_FIX | ENHANCEMENT
## Summary
One paragraph describing the deliverable.
## Requirements
Numbered list of what must be achieved.
## Existing Code Analysis
(Required for BUG_FIX and ENHANCEMENT)
- Files analyzed with line references
- Current behavior description
- Patterns to follow
## Implementation Plan
### Phase 1: Test Specification (RED)
Exact test code to write.
### Phase 2: Implementation (GREEN)
File-by-file checklist of changes.
### Phase 3: Verification
Commands to run and expected results.
## Acceptance Criteria Mapping
Table linking requirements → tests → implementation.
Focus on:
Do NOT:
Critical: Must analyze existing code before planning fix.
Reproduce understanding
Code analysis
Fix design
Critical: Must deeply understand existing code before extending.
Existing code inventory
Extension design
Test design
@Test
void should_[expectedBehavior]_when_[condition]() {
// Given - setup
// When - action
// Then - assertions
}
BAD (too vague):
- Write tests for the service
GOOD (specific):
- Test: should_returnUser_when_validIdProvided
- Given: User with ID=1 exists in repository
- When: findById(1) called
- Then: Returns Optional containing user
#### File: `src/main/java/com/example/UserService.java`
- [ ] Add method: `public User findByEmail(String email)`
- [ ] Add null check for email parameter
- [ ] Throw `IllegalArgumentException` if email is blank
- [ ] Call `userRepository.findByEmail(email)`
- [ ] Return result or throw `UserNotFoundException`
List implementation tasks in dependency order:
Always include exact commands:
### Phase 3: Verification
```bash
# 1. Compile check
mvn compile
# 2. Run specific tests
mvn test -Dtest=UserServiceTest,UserControllerTest
# 3. Run all tests
mvn test
# 4. Run with coverage
mvn test jacoco:report
# Expected: >80% coverage on new code
# 5. Integration tests
mvn verify
## Common Planning Mistakes
| Mistake | Impact | Prevention |
|---------|--------|------------|
| Skipping code analysis for bugs | Wrong fix | Always read existing code first |
| Vague test descriptions | Tests miss cases | Use Given/When/Then |
| Missing error scenarios | Bugs in production | Explicitly list error cases |
| Ignoring existing patterns | Inconsistent code | Document patterns before planning |
| Over-engineering | Wasted effort | Plan only what's required |
## Quality Checklist for Plans
Before finalizing a plan, verify:
- [ ] Task type is clearly identified
- [ ] All requirements are listed and numbered
- [ ] For bugs/enhancements: existing code is analyzed
- [ ] Test cases have Given/When/Then structure
- [ ] Implementation checklist is file-by-file
- [ ] Verification commands are exact and runnable
- [ ] Acceptance criteria maps to tests
- [ ] No ambiguous instructions