Superior Architecture 用于设计、实现或评估项目结构、模块归属、依赖边界以及安全的文件与文件夹组织。它把 Clean Architecture 视为一组边界，而不是必须遵循的目录树，也不是要求增加分层的指令。
使用方式上，先确定范围与证据：判断用户需要的是设计、只读评估还是实现；检查仓库说明、框架入口点与发现规则、现有功能归属、导入关系、测试和相关文档。对新项目，检查实际的框架脚手架和支持的约定，识别现有公共契约和必须保持不变的部分。仅做架构评估并不授权移动文件、更改依赖或重构无关代码；只有当请求与项目证据无法解决实质不同的架构方向时，才需要询问方向。
在归属与分组方面，建立项目结构、把功能拆分到多项职责或判断文件/模块是否需要拆分时，参考项目结构与边界文档。新代码应放在拥有其行为的功能或模块附近，按当前约定、变更模式和框架要求选择基于功能、基于层或混合的组织方式。在能保护真实契约或支持独立测试时，将领域策略与 UI、传输和持久化分离；依赖方向应与既定边界和用户要求保持一致。从当前工作需要的最小结构开始，不要仅为匹配某个命名模式而创建空层、接口、仓库、适配器或服务容器；只在存在真实共享责任或契约时提取共享代码，避免通用兜底文件夹和每个简单函数一个文件。当文件混合不同职责、因无关原因变更、模糊信任边界或难以导航和测试时，可考虑拆分，行数只是检查信号而非硬性阈值。除非用户明确要求更改，否则保留项目既定架构，将重构限制在授权范围内并说明重要权衡。
安全移动与验证方面，移动代码前追踪导入和间接消费方，包括框架发现、路由、配置、注册、包导出、测试、构建脚本和文档化的公共 API；保持行为、验证、错误处理、安全性和兼容性，并同步更新受影响的使用方；公共契约需要时保留或规划兼容路径。使用现有针对性测试以及项目相关的发现、类型、Lint 或构建检查验证受影响行为，并报告所选的归属、依赖方向、重要权衡、兼容性影响、已运行的检查和未解决风险；不要仅凭文件夹名称声称架构干净。
该技能可与其他技能配合：行为、状态转换和业务契约使用 superior-logic；评估不合理复杂度和安全移除使用 superior-lean；对变更做只读审查使用 superior-code-review，当结构边界是主要关注点时叠加本技能；记录已验证的重要变更或更新架构决策时使用 superior-docs。