Required Plugins

Superpowers plugin: MUST be active for all work using this skill. Use throughout the entire build pipeline — design decisions, code generation, debugging, quality checks, and any task where it offers enhanced capabilities. If superpowers provides a better way to accomplish something, prefer it over the default approach.

SDLC Design Skill

Generate a complete Design & Development documentation suite for software development projects. This skill produces 6 design documents that translate requirements (from sdlc-planning) into actionable technical architecture and implementation guidance.

When to Use

• Translating an approved SRS into a technical architecture and system design
• Documenting database schemas, stored procedures, and data models for a new system
• Specifying API contracts for frontend, mobile, and third-party consumers
• Defining interface contracts between system components and external systems
• Establishing code documentation standards before development begins
• Creating technical specifications for complex features or modules

When NOT to Use

• Gathering raw requirements -- use project-requirements skill
• Project-level planning (SDP, QA Plan, Risk Plan) -- use sdlc-planning skill
• Planning a single feature (spec + implementation) -- use feature-planning skill
• Writing test plans and test cases -- use sdlc-testing skill
• Writing deployment or user documentation -- use sdlc-user-deploy skill
• Planning an Android companion app -- use android-saas-planning skill

Document Inventory

Prerequisites

Before generating design documents, ensure these inputs exist:

Generation Workflow

Generate documents in this order. Each builds on the previous.

Step 1: System Design Document (architecture baseline)
    |
Step 2: Database Design Document (data layer foundation)
    |
Step 3: Technical Specification (implementation details)
    |
Step 4: Interface Control Document (component contracts)
    |
Step 5: API Documentation (consumer-facing specs)
    |
Step 6: Code Documentation Standards (team conventions)

Rationale: Architecture drives database design. Database and architecture together inform technical specs. Interface contracts are defined after components are known. API docs are consumer-facing views of interface contracts. Code standards apply across all layers.

Architecture Patterns Supported

Cross-References to Existing Skills

Upstream Skills (use BEFORE this skill)

Parallel Skills (use ALONGSIDE this skill)

Downstream Skills (use AFTER this skill)

Adaptation Rules

SaaS vs Standalone

Mobile + Web vs Web-Only

MVP vs Full Product

Output Structure

When generating design documents for a project, create this structure:

docs/design/
├── 01-system-design-document.md
├── 01-sdd/
│   ├── component-design.md
│   ├── security-architecture.md
│   └── deployment-architecture.md
├── 02-database-design-document.md
├── 02-database/
│   ├── entity-relationship.md
│   ├── table-definitions.md
│   └── stored-procedures.md
├── 03-technical-specification.md
├── 03-tech-spec/
│   ├── module-specifications.md
│   └── algorithm-details.md
├── 04-interface-control-document.md
├── 05-api-documentation.md
├── 05-api/
│   ├── authentication-endpoints.md
│   ├── module-endpoints.md
│   └── error-reference.md
└── 06-code-documentation-standards.md

Each file must stay under 500 lines. Split into subdirectories as needed.

Quality Checklist

Run after generating all documents:

• All 6 documents generated (or justified why one was skipped)
• Each document stays under 500 lines (split if needed)
• SDD references the correct tech stack with version numbers
• SDD includes ASCII architecture diagrams (system context, high-level, deployment) — visual-aid locations marked with [DIAGRAM-PROMPT: <description>]
• Every major design decision includes a ## Design Rationale block: chosen approach, rejected alternatives, trade-off reasoning
• Major architectural decisions captured as Architecture Decision Records (ADRs): Context → Decision → Alternatives Considered → Consequences
• Database Design references mysql-best-practices skill, not duplicate it
• All tenant-scoped tables include franchise_id column
• API Documentation references api-error-handling and api-pagination skills
• ICD covers all interface types (backend-mobile, backend-web, external)
• Technical Spec includes real PHP/Kotlin/SQL code examples in fenced code blocks with language identifiers
• Code Documentation Standards cover PHP, Kotlin, and SQL
• Security architecture addresses dual auth, RBAC, encryption, audit trails
• Deployment environments (Windows dev, Ubuntu staging, Debian prod) documented
• All documents cross-reference each other and upstream SRS
• No vague language -- all specifications are measurable and concrete
• Examples are tailored to the project's actual tech stack and domain

Anti-Patterns (What NOT to Do)

Template Files

Each template provides the complete structure, section-by-section guidance, example excerpts, anti-patterns, and a quality checklist.

1. System Design Document
2. Technical Specification
3. Interface Control Document
4. Database Design Document
5. Code Documentation Standards
6. API Documentation

Back to: Skills Repository Related: sdlc-planning | feature-planning | mysql-best-practices | api-error-handling Last Updated: 2026-03-15 (strengthened per Adjei 2023, Winston, Etter 2016)