Back to list
jsegov

sdd-template

by jsegov

Spec Driven Development Plugin for Claude Code

8🍴 0📅 Jan 14, 2026

SKILL.md


name: sdd-template description: This skill should be used when the user asks to "create a design document", "write technical specs", "document architecture", "generate SDD", "design the system", "API design", or when creating technical design documents from approved PRDs. version: 0.1.0

Software Design Document Template

Create comprehensive technical design documents following the Atlassian 8-section structure.

Document Structure Overview

SectionPurpose
1. IntroductionPurpose, scope, definitions
2. System OverviewHigh-level architecture
3. Design ConsiderationsAssumptions, constraints, risks
4. Architectural StrategiesKey decisions and alternatives
5. System ArchitectureComponents, data flow, APIs, models
6. Policies and TacticsSecurity, error handling, logging
7. Detailed DesignComponent-level specifications
8. AppendixDiagrams, glossary

Section Templates

Section 1: Introduction

## 1. Introduction

### 1.1 Purpose
[What this document covers and its intended audience]

### 1.2 Scope
[System boundaries - what's included and excluded]

### 1.3 Definitions and Acronyms
| Term | Definition |
|------|------------|
| [Term] | [Definition] |

### 1.4 References
- PRD: [link to PRD document]
- [Other relevant documents]

Section 2: System Overview

## 2. System Overview

### 2.1 System Context
[How this system fits into the broader architecture]

### 2.2 High-Level Architecture
[Architecture diagram description or ASCII diagram]

### 2.3 Key Components
- **Component A**: [Purpose and responsibility]
- **Component B**: [Purpose and responsibility]

Section 3: Design Considerations

## 3. Design Considerations

### 3.1 Assumptions
- [Assumption 1]
- [Assumption 2]

### 3.2 Constraints
- [Technical constraint]
- [Business constraint]

### 3.3 Dependencies
- [External system X]
- [Library Y version Z]

### 3.4 Risks
| Risk | Impact | Mitigation |
|------|--------|------------|
| [Risk] | High/Med/Low | [Strategy] |

Section 4: Architectural Strategies

## 4. Architectural Strategies

### 4.1 Strategy Selection
[Why this architecture was chosen over alternatives]

### 4.2 Alternatives Considered
| Option | Pros | Cons | Decision |
|--------|------|------|----------|
| [Option A] | [Pros] | [Cons] | Selected |
| [Option B] | [Pros] | [Cons] | Rejected |

### 4.3 Key Architectural Decisions
- **Decision 1**: [Decision and rationale]
- **Decision 2**: [Decision and rationale]

Section 5: System Architecture

## 5. System Architecture

### 5.1 Component Diagram
[Description or ASCII representation]

### 5.2 Data Flow
[How data moves through the system]

### 5.3 API Design

#### 5.3.1 Endpoints
| Method | Path | Description |
|--------|------|-------------|
| POST | /api/resource | Create resource |
| GET | /api/resource/:id | Get resource |

#### 5.3.2 Request/Response Schemas
[TypeScript interfaces or JSON schemas]

### 5.4 Data Models
[Database schema with types and constraints]

Section 6: Policies and Tactics

## 6. Policies and Tactics

### 6.1 Security
- Authentication: [Strategy]
- Authorization: [Strategy]
- Data encryption: [At rest / in transit]

### 6.2 Error Handling
- [Error handling strategy]
- [Retry policies]

### 6.3 Logging and Monitoring
- [What to log]
- [Alerting thresholds]

### 6.4 Performance
- [Caching strategy]
- [Connection pooling]

Section 7: Detailed Design

## 7. Detailed Design

### 7.1 [Component A] Design

#### 7.1.1 Responsibilities
- [Responsibility 1]
- [Responsibility 2]

#### 7.1.2 Interface
[TypeScript interface or function signatures]

#### 7.1.3 Implementation Notes
[Specific implementation details, algorithms, or patterns]

Section 8: Appendix

## 8. Appendix

### 8.1 Sequence Diagrams
[For complex flows]

### 8.2 State Diagrams
[For stateful components]

### 8.3 Glossary
[Extended definitions]

Requirement Traceability

Each design decision should trace to requirements:

### REQ-001 Implementation
**Requirement:** [Quote requirement]
**Design:** [How this design satisfies it]
**Verification:** [How to test it]

Quality Checklist

Before finalizing an SDD:

  • Every PRD requirement (REQ-XXX) is addressed
  • Data models are complete with types and constraints
  • API contracts are fully specified
  • Error scenarios are documented
  • Security considerations are addressed
  • Performance requirements have corresponding strategies
  • Dependencies are versioned
  • Diagrams are included where helpful

Additional Resources

For detailed section guidance and examples, see references/sections.md.

Score

Total Score

65/100

Based on repository quality metrics

SKILL.md

SKILL.mdファイルが含まれている

+20
LICENSE

ライセンスが設定されている

+10
説明文

100文字以上の説明がある

0/10
人気

GitHub Stars 100以上

0/15
最近の活動

1ヶ月以内に更新

+10
フォーク

10回以上フォークされている

0/5
Issue管理

オープンIssueが50未満

+5
言語

プログラミング言語が設定されている

+5
タグ

1つ以上のタグが設定されている

+5

Reviews

💬

Reviews coming soon