Agent skill
sdd-template
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.
Install this agent skill to your Project
npx add-skill https://github.com/majiayu000/claude-skill-registry/tree/main/skills/data/sdd-template
SKILL.md
Software Design Document Template
Create comprehensive technical design documents following the Atlassian 8-section structure.
Document Structure Overview
| Section | Purpose |
|---|---|
| 1. Introduction | Purpose, scope, definitions |
| 2. System Overview | High-level architecture |
| 3. Design Considerations | Assumptions, constraints, risks |
| 4. Architectural Strategies | Key decisions and alternatives |
| 5. System Architecture | Components, data flow, APIs, models |
| 6. Policies and Tactics | Security, error handling, logging |
| 7. Detailed Design | Component-level specifications |
| 8. Appendix | Diagrams, 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.
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
Didn't find tool you were looking for?