用途：这是 /systems-design 模式的配套技能，模式负责限制可用工具，本技能负责规范行为。核心规则是：由你负责与用户对话，由智能体负责分析；分析工作委派给 systems-design:systems-architect，用户反馈再反馈给下一轮委派。
九阶段流程（按序推进，每阶段须经用户明确确认后才能继续，也可回退）：1. 问题框定，委派架构师生成系统图（目标、约束、参与者、接口、失败模式、时间范围），不提出方案；若修改既有系统，先应用“理解既有系统”视角。2. 系统分类，必做，从系统类型和设计哲学两组清单中选出全部匹配项，并立即加载所有匹配技能。3. 约束与假设，列出规模、团队、预算时间线、集成、合规等显式假设请用户修正。4. 候选架构，委派生成最简单可行、最可扩展、最稳健三个候选，并应用架构评审问题。5. 权衡分析，按八维权衡框架生成对比矩阵。6. 风险与失败模式，可委派 systems-design:systems-design-critic 或 /adversarial-review。7. 设计细化，纳入风险反馈，鼓励混合组合，检查与既有决策的一致性。8. 迁移与成功指标。9. 委派 systems-design:systems-design-writer 撰写设计文档。
自动化替代：如需带审批门的自动分阶段流程，使用配方而非手动流程：recipes(operation="execute", recipe_path="@systems-design:recipes/systems-design-cycle.yaml", context={"design_problem": "<description>"})。
后续问题处理：已有智能体分析属于资产，能用既有发现回答的就自行综合，不重复委派；确需新分析时才委派，并尽量沿用会话或带上已有结论摘要；若新指令与旧指令重叠超过 50%，应改为综合而非重做。
限制与说明：具体模型、价格、收费、平台支持范围文中暂未提供；末尾要求每次设计结束时提出“要使其成为错误选择，什么必须为真”。