sdlc-design（SDLC 设计）

Platform Notes

• Optional helper plugins may help in some environments, but they must not be treated as required for this skill.

SDLC Design Skill

Use When

• Generate Design & Development documentation for SDLC projects. Covers System Design Document (SDD), Technical Specification, Interface Control Document (ICD), Database Design Document, Code Documentation standards, and API Documentation. Use when...
• The task needs reusable judgment, domain constraints, or a proven workflow rather than ad hoc advice.

Do Not Use When

• The task is unrelated to sdlc-design or would be better handled by a more specific companion skill.
• The request only needs a trivial answer and none of this skill's constraints or references materially help.

Required Inputs

• Gather relevant project context, constraints, and the concrete problem to solve; load templates only as needed.
• Confirm the desired deliverable: design, code, review, migration plan, audit, or documentation.

Workflow

• Read this SKILL.md first, then load only the referenced deep-dive files that are necessary for the task.
• Apply the ordered guidance, checklists, and decision rules in this skill instead of cherry-picking isolated snippets.
• Produce the deliverable with assumptions, risks, and follow-up work made explicit when they matter.

Quality Standards

• Keep outputs execution-oriented, concise, and aligned with the repository's baseline engineering standards.
• Preserve compatibility with existing project conventions unless the skill explicitly requires a stronger standard.
• Prefer deterministic, reviewable steps over vague advice or tool-specific magic.

Anti-Patterns

• Treating examples as copy-paste truth without checking fit, constraints, or failure modes.
• Loading every reference file by default instead of using progressive disclosure.

Outputs

• A concrete result that fits the task: implementation guidance, review findings, architecture decisions, templates, or generated artifacts.
• Clear assumptions, tradeoffs, or unresolved gaps when the task cannot be completed from available context alone.
• References used, companion skills, or follow-up actions when they materially improve execution.

Evidence Produced

References

• Use the templates/ directory when the task needs a structured deliverable.

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.

Load Order

1. Load world-class-engineering.
2. Load system-architecture-design and database-design-engineering.
3. Load this skill to turn approved requirements into executable design artifacts.

Executable Design Standard

Design documents must define:

• critical flows, invariants, and failure handling
• release-aware architecture and migration posture
• observability, audit, and operational ownership expectations
• contract evolution rules for live systems

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
• Rollout, migration, and rollback posture are explicit for live systems
• 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

References

• ../sdlc-lifecycle.md: Shared SDLC execution model and lifecycle gates.

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)