Agent Skills › winstonkoh87/Athena-Public › Spec-Driven Development

Spec-Driven Development

GitHub

通过强制提问和编写详细设计规格书，在编码前明确需求、边界与验收标准，防止因理解偏差导致的开发失败。适用于复杂功能或耗时任务，确保代码实现严格遵循已批准的设计方案。

examples/skills/coding/spec-driven-dev/SKILL.md winstonkoh87/Athena-Public

触发场景

用户提出复杂功能需求涉及多文件修改的任务预估开发时间超过30分钟的任务需要明确非功能性约束的场景

安装

npx skills add winstonkoh87/Athena-Public --skill Spec-Driven Development -g -y

更多选项

非标准路径

npx skills add https://github.com/winstonkoh87/Athena-Public/tree/main/examples/skills/coding/spec-driven-dev -g -y

不安装直接使用

npx skills use winstonkoh87/Athena-Public@Spec-Driven Development

指定 Agent (Claude Code)

npx skills add winstonkoh87/Athena-Public --skill Spec-Driven Development -a claude-code -g -y

安装 repo 全部 skill

npx skills add winstonkoh87/Athena-Public --all -g -y

预览 repo 内 skill

npx skills add winstonkoh87/Athena-Public --list

SKILL.md

Frontmatter

{
    "name": "Spec-Driven Development",
    "model": "default",
    "created": 1772150400,
    "auto-invoke": false,
    "description": "Interrogates the user to build a complete design specification before writing any code. Prevents \"vibe coding\" failures.",
    "context_trigger": "build app, create feature, new project, spec out, design doc, requirements, let's build, software project"
}

📋 Spec-Driven Development

Philosophy: 55 minutes defining the problem, 5 minutes solving it.

1. The Problem

Most AI coding failures happen because the agent starts coding before understanding:

What the user actually wants (vs. what they said)
Edge cases and constraints
Integration points and dependencies
Success criteria

2. Execution Workflow

PHASE 1: INTERROGATION (No Code Allowed)
  ├─ "What is the ONE thing this must do?"
  ├─ "What does success look like? Be specific."
  ├─ "What are 3 things this must NOT do?"
  ├─ "Who/what does this interact with?"
  └─ "What's the simplest version that would be useful?"

PHASE 2: SPEC DOCUMENT
  └─ Write a design.md with:
     ├─ Goal (1 sentence)
     ├─ Requirements (numbered list)
     ├─ Non-Requirements (explicit exclusions)
     ├─ Architecture (how components connect)
     ├─ Edge Cases (what could go wrong)
     └─ Acceptance Criteria (how to verify)

PHASE 3: USER APPROVAL
  └─ Present spec for review
  └─ DO NOT proceed to code until approved

PHASE 4: IMPLEMENTATION
  └─ Code against the approved spec
  └─ Reference spec line items in commits

3. The Spec Template

# Design Spec: [Feature Name]

## Goal
[One sentence describing what this does]

## Requirements
1. [Must do X]
2. [Must handle Y]
3. [Must integrate with Z]

## Non-Requirements (Out of Scope)
- [Will NOT do A]
- [Will NOT support B]

## Architecture
[How the components connect — diagram or description]

## Edge Cases
- [What if input is empty?]
- [What if API is down?]
- [What if user does X instead of Y?]

## Acceptance Criteria
- [ ] [Testable condition 1]
- [ ] [Testable condition 2]