用途
Design Integrity 是一个来自 robsonrung/rar-skills 的设计技能，主题为由 Brooks 启发的设计纪律：在实现推进使错误形态固化之前，有意识地塑造设计。它用于在编码之前或编码过程中审查和塑造软件设计，以保持概念完整性。当用户要求设计或审查架构、API 界面等内容时适用。
主要能力
该技能围绕一组操作规则与工作流展开。操作规则包括：把用户提出的请求视为起点而非完整问题；保持概念完整性，即一个清晰的模型、一致的词汇、连贯的边界和可预测的接口；优先选择小而一致的设计，而不是概念分裂的宽泛设计；把现有代码库作为范例来源，匹配其最强的本地模式，除非这些模式本身就是问题；仅在不确定性会改变决策时制作原型，并丢弃原型或明确标记为临时；仅在决策取决于产品意图、运营风险或代码库无法揭示的权衡时，且在以实际方式解释权衡之后，才向用户征询输入。
其工作流包含：框定真正的设计问题（用户目标、受影响的用户或调用方、当前系统行为、期望行为、当前形态不足的原因）；发现约束（不变量、既有契约、数据所有权、命名约定、性能限制、安全边界、迁移成本、测试接缝、部署或回滚约束）；定义设计成功标准（连贯性、简单性、可测试性、可维护性及相关用户可见行为）；搜索设计空间（当改动涉及架构、数据流、公共 API、持久化、权限、UI 工作流或跨模块契约时，产出至少两种可行的方案形态，并说明每种形态的核心想法、简化了什么、复杂化了什么以及如何契合或冲突于现有系统）；选择最小的连贯形态（在已知约束下最大程度保持概念完整性的设计，并在工作量较大时用一小段话解释决定性权衡）；按所选形态实现（保持名称、边界和数据流与所选概念一致，避免加入解决局部问题却削弱中心模型的旁路）；验证设计（运行相关测试或检查，然后审查实现是否仍有一个清晰的想法、边界情况是否遵循同一模型、未来维护者能否预测改动应归属何处）。
使用方式
该技能提供一份审查清单，用于在最终确定设计重度改动之前检查：真实问题是否被命名；是否搜索了隐藏需求和约束；是否考虑了至少两种备选方案，或改动小到足以跳过这一步；概念完整性：设计是否有单一中心概念；名称是否与概念匹配；改动所有权：边界是否与所有权匹配，使一项改动只希望存在于一个地方；最小连贯形态：设计是否不大于问题所需；测试或验证是否覆盖主要契约。应用时应为每项检查命名，例如“这保持了概念完整性，但代价是改动所有权——两个模块将一起移动”，以使权衡可读。
在规划或审查时使用该技能，需返回输出契约：design_problem（正在解决的真正问题）、constraints（重要约束和假设）、alternatives（考虑过的可行方案形态）、recommendation（选定的形态和决定性权衡）、conceptual_integrity_check（结果是否有一个连贯模型）、validation（所使用的测试、检查、原型或证据）。在实现过程中使用该技能时，保持最终答案简洁，并包含设计决策、改动的文件和执行的验证。
适用场景
适用于在编码前或编码中设计和审查软件架构、API 界面等需要保持概念完整性的设计工作，以及在实现过程中需要遵循既定设计形态的场景。
限制
资料中列出的注意事项包括：不要把每个小 bug 修复都变成架构练习；当请求是关于修复一个损坏的模型时，不要盲目保留现有模式；不要混淆一致性与概念完整性——一致地重复旧错误仍然是设计问题。
其他信息
该技能的官方文本、收费、价格、平台和具体使用步骤在资料中暂未提供。