Implements features from technical specifications using TDD. Use when: repo contains /docs/specs/*.md, task references acceptance criteria (AC-*), .claude/current_task.json exists, or user mentions "implement the spec", "work on AC-", or "test first".
/plugin marketplace add ViktorDolezel/spec-driven-dev/plugin install viktordolezel-spec-driven-dev@ViktorDolezel/spec-driven-devThis skill inherits all available tools. When active, it can use any tool Claude has access to.
current-task-schema.jsonevaluations.mdfailure-types.mdsession-schema.yamlspec-checklist.mdTask Progress:
- [ ] Validate spec quality (see spec-checklist.md)
- [ ] Read spec and current_task.json
- [ ] For each AC: write test → implement → verify → commit
- [ ] Update current_task.json after each AC
- [ ] Create session log before ending
| File | Purpose |
|---|---|
/docs/specs/{feature}.md | What to build (source of truth) |
.claude/current_task.json | Your assignment and progress |
.claude/sessions/*.yaml | Session history (read previous, write yours) |
If .claude/current_task.json doesn't exist, create it:
{
"spec": "/docs/specs/{feature}.md",
"branch": "{current git branch}",
"started_at": "{ISO 8601 timestamp}",
"progress": { "acceptance_criteria": [] }
}
Before implementing ANY spec, validate quality using spec-checklist.md.
Required gates (must pass):
If validation fails: Stop and request spec revision. Do not implement low-quality specs.
For each acceptance criterion, copy and complete:
AC-{N}:
- [ ] Read AC (Given/When/Then, constraints)
- [ ] Write test that fails (see Test Quality Rules below)
- [ ] Implement until test passes
- [ ] Add provenance comment
- [ ] Commit: [AC-{N}] {description}
- [ ] Update current_task.json status to "passed"
A valid failing test must:
Examples:
❌ Bad - Fake failing test:
test('AC-1: validates email', () => {
expect(true).toBe(false) // Fails but tests nothing
})
❌ Bad - Too weak:
test('AC-1: validates email', () => {
const result = validateEmail('test@example.com')
expect(result).toBeDefined() // Passes even with stub
})
✅ Good - Specific assertion:
test('AC-1: rejects invalid email format', () => {
const result = validateEmail('not-an-email')
expect(result.isValid).toBe(false)
expect(result.error).toBe('INVALID_FORMAT')
})
Acceptable failure messages (before implementation):
validateEmail is not defined - function doesn't exist yetexpected false but got undefined - logic not implementedCannot read property 'isValid' of undefined - return value missingNotImplementedError: validateEmail not yet implemented - explicit stubUnacceptable failure reasons (fix test first):
Before implementing: Verify test fails with acceptable message. If not, fix the test.
Every implementation file must reference its spec:
// Implements: /docs/specs/password-reset.md#AC-1
// Implements: /docs/specs/password-reset.md#AC-2
// Error: E001 (from spec error catalog)
[AC-1] {what changed}
Examples:
[AC-1] add validation schema[AC-1] implement endpoint[AC-1] fix timezone handlingBlocked? →
├─ Can proceed with documented assumption? → Continue, flag for review
├─ Missing resource (mock, data, access)? → Skip AC, continue others
└─ Neither? → Stop. Document. Do not guess.
Record in session log:
failures:
- type: spec_ambiguous|mock_missing|tool_failure|permission_denied
detail: "{specific description}"
resolution: "{what you did or 'blocked'}"
Failure types: See failure-types.md
Before ending, create .claude/sessions/{YYYY-MM-DD}-{4-random-chars}.yaml:
session_id: {4 random chars}
timestamp: {ISO 8601}
spec: {path to spec}
branch: {git branch}
work_completed:
- ac_id: AC-1
outcome: passed # or: failed, blocked, skipped
attempts: 1
failures: [] # or list of {type, detail, resolution}
handoff: |
{What's done}
{What's in progress}
{What to watch out for}
Commit the session log before ending.
This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs guidance on slash command structure, YAML frontmatter fields, dynamic arguments, bash execution in commands, user interaction patterns, or command development best practices for Claude Code.
This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.
This skill should be used when the user asks to "create a hook", "add a PreToolUse/PostToolUse/Stop hook", "validate tool use", "implement prompt-based hooks", "use ${CLAUDE_PLUGIN_ROOT}", "set up event-driven automation", "block dangerous commands", or mentions hook events (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification). Provides comprehensive guidance for creating and implementing Claude Code plugin hooks with focus on advanced prompt-based hooks API.