Skip to content
Back to skills

Sdd Design

ASecurity

Architecture and interface design for spec-driven development

  • 9 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 11, 2026
ai-agentsgorefactoringdatabase

Security analysis

A100/100

Scanned October 11, 2026

npx -y skills add PedroMosquera/squadai --skill sdd-design --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Sdd Design?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Sdd Design
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/pedromosquera-sdd-design/badge)](https://www.skillsdirectory.com/skills/pedromosquera-sdd-design)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: sdd-design
description: Architecture and interface design for spec-driven development
methodology: sdd
---

# SDD Design Skill

Translate a specification into a concrete architecture. Define module
boundaries, interface contracts, and data flow before any code is written.

## Steps

1. **Identify modules**: Break the system into coherent units.
   - Each module should have a single responsibility
   - Modules communicate through defined interfaces (not direct access)
   - Internal implementation of each module is hidden from others

2. **Define interfaces**: Specify the contract between modules.
   - Interface name and methods with full signatures
   - Which module implements each interface
   - Which modules consume each interface
   - Avoid leaking implementation details through interfaces

3. **Design data flow**: Map how data moves through the system.
   - Input sources and entry points
   - Transformation steps
   - Storage points (databases, files, caches)
   - Output destinations

4. **Draw architecture diagrams**: Use text-based diagrams.
   ```
   [Input] → [Parser] → [Validator] → [Processor] → [Output]
                                            ↓
                                       [Storage]
   ```

5. **Specify error propagation**: Define how errors flow.
   - Which errors are recoverable vs fatal?
   - Where are errors wrapped with context?
   - Which errors bubble up to the caller vs are handled locally?
   - Sentinel error values for expected failures

6. **Identify extension points**: Design for known future needs.
   - Where will new implementations be added (registry, plugin patterns)?
   - Which interfaces should be kept minimal to avoid coupling?
   - What should remain internal to allow refactoring?

7. **Validate against the spec**: Check each design decision against constraints.
   - Does the design satisfy all interface contracts in the spec?
   - Does it meet non-functional requirements?
   - Is it testable (can dependencies be injected or mocked)?

## Output Format

```
## Design: <feature name>

### Module Structure
- **<module>**: <responsibility>
  - Implements: <interface>
  - Depends on: <interfaces>

### Interfaces

#### <InterfaceName>
```go
type InterfaceName interface {
    Method(param Type) (ReturnType, error)
}
```
Implemented by: <types>
Consumed by: <modules>

### Data Flow
```
[source] → [module] → [module] → [destination]
```

### Error Handling
| Error | Type | Where handled | How propagated |
|-------|------|---------------|----------------|

### Architecture Diagram
```
<ASCII diagram>
```

### Design Decisions
1. <decision>: <rationale and alternatives considered>
```

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…