应用新写法前，它会先核对项目支持的系统版本和 Xcode 工具链。然后查看 API、页面结构和数据处理方式，例如建议用foregroundStyle()设置前景样式，用NavigationStack组织页面跳转。

页面代码过长时，它会建议拆成独立的子视图，把按钮操作和业务逻辑放到合适的位置。共享数据、输入框绑定、列表条目标识，以及详情页和弹窗怎样接收数据，也在检查范围内。

动画、拖动排序和滑动操作都有各自的规则。它会把这些交互和页面代码一起检查。页面与动画规则

设计规则会检查字体、颜色和间距是否统一，空列表和搜索无结果时是否用了合适的系统组件。布局规则则会考虑窗口缩小、iPad 多任务、文字变长和字号放大后的情况。

无障碍部分很细。它会检查 VoiceOver，也就是系统的屏幕朗读功能，是否能说清按钮用途；还会查看页面有没有尊重用户的字号和“减少动态效果”设置。

仓库里的按钮示例很直观。一个加号按钮，会被建议补上“添加用户”这样的文字标签。界面仍可以只显示图标，但朗读时能说清它会做什么。用颜色区分状态的地方，也会检查是否需要图标或其他标记。无障碍规则

界面可以只显示图标，文字标签让屏幕朗读功能说清按钮用途。

它会检查新文字是否放进了项目已有的翻译资源，资源包是否选对，以及容易产生歧义的词有没有给翻译者留下说明。

日期、数字和文字搜索也有对应的 Swift 规则。比如，日期显示要考虑用户的地区习惯，页面使用的日历和时区要与当前环境一致。这些细节会和普通界面文字一起检查。多语言规则

性能检查很具体。页面每次刷新时是否又做了一遍排序和筛选，长列表是否一次创建了太多内容，一个条目变化时是否带着其他条目一起更新，都是它关注的地方。

它也会查看异步任务的安排。遇到已经确认的频繁刷新问题，仓库还有单独的深入性能资料，用来分析页面读取了哪些数据、更新能否缩小到更少的部分。性能规则

Swift 规则会查看异步代码是否采用合适的async/await写法，共享数据的修改有没有得到保护，以及用户操作失败时是否有清楚的提示。

它还会查看核心逻辑有没有测试，需要解释的代码有没有注释，敏感信息是否放在合适的位置。项目已经配置 SwiftLint 时，也会关注相关检查结果。

如果已经配置 Xcode MCP，它会优先使用对应工具。预览工具可以提供 SwiftUI 页面图像，文档搜索工具可以查 Apple 的用法说明，方便把代码和页面放在一起看。项目检查规则

它规定的报告格式很实用。问题按文件整理，每一项写清文件和行号、涉及的规则，再附上简短的修改前后代码。

最后还会按影响程度排列建议。拿到报告后，可以找到对应位置，看懂为什么要改，再决定先处理哪一项。核心 Skill 文档