System Design 是一个面向软件架构与系统设计的技能，来自 qodex-ai/ai-agent-skills。根据资料，其用途是设计与架构软件系统，规划系统组件、交互方式以及部署模式，以兼顾可扩展性和可维护性。该技能以整洁架构（Clean Architecture）和领域驱动设计（Domain Driven Design）原则为基础，为高质量导向的软件开发与架构提供指导。
主要能力与规范
该技能给出了多个层面的规则与建议。
代码风格规则方面：通用原则包括尽可能使用提前返回（early return）模式以替代嵌套条件、通过创建可复用函数与模块避免代码重复、将超过 80 行的组件与函数拆分为更小的组件与函数（若无法被其他地方复用则保留在同一文件，但文件超过 200 行代码时应拆分为多个文件），以及在可能的情况下使用箭头函数代替函数声明。
库优先方法（Library-First Approach）方面：在编写自定义代码之前始终先搜索现有解决方案，检查 npm 上是否已有解决该问题的库，评估现有的服务/SaaS 方案，针对常见功能考虑使用第三方 API。建议使用库而不是自己编写工具或辅助函数，例如使用 cockatiel 而不是自己实现重试逻辑。当自定义代码确实合理时，列举的情形包括：领域独有的特定业务逻辑、有特殊要求的性能关键路径、外部依赖属于过度设计、需要完全控制的安全敏感代码，以及在充分评估后现有方案仍不满足需求。
架构与设计方面：遵循领域驱动设计和统一语言（ubiquitous language）；将领域实体与基础设施关注点分离；使业务逻辑独立于框架；清晰定义用例并保持隔离。
命名约定方面：避免使用泛化名称，如 utils、helpers、common、shared；使用领域特定名称，如 OrderCalculator、UserAuthenticator、InvoiceGenerator；遵循限界上下文（bounded context）的命名模式；每个模块应有单一且清晰的用途。
关注点分离方面：不要将业务逻辑与 UI 组件混在一起；不要把数据库查询放进控制器；保持上下文之间的清晰边界；确保职责划分得当。
需要避免的反模式
该技能列出了若干需要规避的做法。一是 NIH（Not Invented Here）综合症：在已有 Auth0/Supabase 的情况下不要自建认证；不要自己写状态管理而不使用 Redux/Zustand；不要自己造表单校验而不使用成熟库。二是不良架构选择：将业务逻辑与 UI 组件混用；在控制器中直接进行数据库查询；缺乏清晰的关注点分离。三是泛化命名反模式：utils.js 中放入 50 个互不相关的函数；helpers/misc.js 成为杂物堆；common/shared.js 用途不明。资料还强调，每一行自定义代码都是需要维护、测试和文档化的负担。
代码质量方面
资料给出的要求包括：使用带类型的 catch 块进行恰当的错误处理；将复杂逻辑拆分为更小、可复用的函数；避免过深嵌套（最多 3 层）；让函数保持聚焦，尽可能不超过 50 行；让文件保持聚焦，尽可能不超过 200 行代码。
使用方式与适用场景
根据资料，该技能作为架构与代码结构方面的指导性规则集使用，适用于需要在智能体辅助下进行软件系统设计、架构规划和代码组织约束的开发工作。其安装方式、运行平台、具体调用方式以及是否收费等信息，资料中暂未提供。