用途
System Design 是一个面向独立开发者的系统设计诊断技能。它的作用是在需求已经验证之后，帮助开发者把需求转化为架构决策、组件设计和接口定义，同时避免两个极端：设计不足（under-engineering）和过度设计（over-engineering）。它不替开发者做决定，而是通过诊断、提问和引导，让开发者自己做出并记录决策。
核心原则是：设计源于约束，每个架构决策都是对其它东西的权衡，要在权衡变成缺陷之前把它明确出来。
主要能力
该技能通过七个状态（SD0–SD6）来诊断当前设计思考所处的问题阶段：
- SD0 需求不清晰：在需求明确前就开始架构，无法说明架构服务于什么问题。干预方式是回到需求分析，或至少写一段问题描述、列出 3–5 项系统必须做的事、列出真实约束。
- SD1 设计不足：没有关注点分离，数据库模式“以后再说”，不考虑数据流和错误处理。干预方式包括数据流映射、关键路径错误场景枚举、变更可能性评估、组件识别。
- SD2 过度设计：为假设的未来做抽象，独立项目上微服务，没有问题却套用模式。干预方式包括 YAGNI 审计、复杂度预算、“什么会坏”测试、抽象计数、三次法则。
- SD3 缺失集成点：孤立构建，不考虑连接对象，API 设计不考虑客户端，忽略认证、日志、部署。干预方式包括关键边界的接口优先设计、依赖清单、集成检查表、边界识别。
- SD4 风险决策未识别：没有显式架构决策记录，无法说明为何选此方案而非替代方案。干预方式包括 ADR、可逆成本评估（易/中/难）、假设日志、决策审计。
- SD5 没有可运行骨架：所有组件设计完成才集成，没有端到端路径。干预方式包括可运行骨架定义、集成顺序规划、首个垂直切片识别、风险优先集成。
- SD6 设计已验证：架构支持需求且无冗余，风险决策有记录，集成点已识别，可运行骨架已定义，可以开始实现。
技能还提供按阶段划分的关键问题（需求导入、架构决策、组件设计、集成规划），以及健康检查问题，用于自查设计是否服务于需求、哪些决策难以逆转、最简单的可行方案是什么、集成点在哪里、能否构建可运行骨架验证架构等。
使用方式
当需求清晰后开始系统设计时，诊断流程为：确认需求存在（若未达到 RA5 则返回）；倾听状态症状，判断当前设计思考处于哪个状态；从最早的问题状态开始，不跳步；提出该状态的关键问题；应用相应干预手段；产出重要决策的工件；定义可运行骨架，明确先构建什么。
该技能会把主要输出写入文件以便跨会话持久化。开始前先检查项目中的 context/output-config.md，若找到则查看本技能条目；若未找到或没有本技能条目，先询问用户保存位置，建议 docs/design/ 或 docs/architecture/，并存储用户偏好。持久化内容包括：设计上下文简报、架构决策记录（ADR）、组件图、可运行骨架定义、验证设计文档。文件命名模式为 design-{project-name}.md 作为概览，ADR 放在 adr/ 文件夹，例如 design-static-site-generator.md、adr/001-markdown-parser-choice.md。
适用场景
适用于独立开发者在需求验证后、开始实现前进行架构设计。典型场景包括：为静态站点生成器等个人项目确定架构；在多个可行架构之间做选择；在技术决策前需要调研；需要记录难以逆转的决策及其理由。技能可与 requirements-analysis（需求验证后作为设计主要输入）、brainstorming（多个架构看似可行时先探索）、research（技术决策需要调研时先研究再写 ADR）配合使用。
限制
该技能不编写实现代码；不跳过需求（需求不清晰时退回需求分析）；不鼓励为假设需求过度设计；不允许隐式决策不被记录；不批准未定义可运行骨架的设计。它只做诊断、提问和引导，最终由开发者决定。技能还列出若干反模式供识别：架构宇航员、隐式决策、大爆炸集成、金锤子、过早优化、依赖否认、简历驱动开发。
参考来源
该技能操作化了以下概念：references/development-process.md（架构权衡三角、ADR、质量属性）、可运行骨架模式（Alistair Cockburn）、YAGNI 原则（极限编程）、架构决策记录（Michael Nygard）。