system-design

用途：面向开放式系统设计问题，从模糊提示出发，通过显式推理得到可论证的架构，而非套用记忆中的架构图。核心观点是不要记忆架构，而要理解塑造架构的约束力；同一方案在 1,000 用户与 1,000,000 用户下可能完全不同，架构应视为假设，约束变化时就应重新设计。\n\n主要能力：内置一个六步推理循环——澄清需求、估算规模、提出高层设计、评估权衡、压力测试失败模式、迭代深入。每一步都有对应技能可调用，例如 requirements-scoping、back-of-the-envelope、api-design、data-storage、caching、load-balancing、messaging-streaming、consistency-coordination、resilience-failure、observability 等共 21 个构建块，按需展开而不从记忆重建。\n\n使用方式：通过 /design <system> 命令运行完整循环，或由 system-design-orchestrator 智能体调度；当问题只涉及某一组件时，可直接触发对应构建块技能。使用 assets/requirements-template.md 记录功能、非功能与范围，用 assets/design-doc-template.md 撰写设计文档，并借助 architecture-diagram 技能绘制架构图，最终将成果写入 docs/design/<system>.md 等文件。\n\n适用场景：系统设计面试准备、架构方案评审前的推演、需要明确权衡与失败处理的开放式设计讨论。\n\n限制：资料未提供具体收费、价格或平台支持信息；技能本身不直接给出唯一正确答案，成功取决于是否把假设显式化。遇到真正模糊且影响设计的需求时应向用户提问，不应静默猜测。