ECC swift-reviewer面向 Kiro 的分层 Swift 代码审查代理设计与全量审查标准【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC本篇指南以 ECC 仓库中 Kiro 代理定义文件 .kiro/agents/swift-reviewer.md 为主体完整解析这位资深 Swift 代码审查者的调用流程、CRITICAL/HIGH/MEDIUM 三级审查标准、诊断命令集与审批决策规则并结合仓库中同名的 Claude Code 版本代理 agents/swift-reviewer.md、配套技能 skills/swift-actor-persistence/SKILL.md、skills/swift-protocol-di-testing/SKILL.md 以及 rules/swift/security.md 做源码级佐证。读完后你将掌握一套可直接落地到 Swift 项目的 AI 审查流程从swift build/swiftlint/swift test前置检查到逐条对齐安全、错误处理、并发、内存、协议导向设计的审查清单再到 Approve/Warning/Block 的审批判定。代理定位与配置.kiro/agents/swift-reviewer.md采用 Kiro 的 Markdown 代理定义格式YAML frontmatter 声明元信息正文即注入给模型的系统提示词。其 frontmatter 完整内容如下name: swift-reviewer description: Expert Swift code reviewer specializing in protocol-oriented design, value semantics, ARC memory management, Swift Concurrency, and idiomatic patterns. Use for all Swift code changes. MUST BE USED for Swift projects. allowedTools: - read - shell各字段的作用可以直接从配置本身读出name代理在 Kiro 中的注册名用于在会话中按名称调用description触发描述。特别值得注意的是其中的强制性措辞——Use for all Swift code changes. MUST BE USED for Swift projects.即凡是涉及 Swift 代码变更的场景都应路由到该代理这是 ECC 代理体系中典型的单用途专家代理命名法仓库agents/目录下还有python-reviewer、rust-reviewer等同构定义allowedTools只授予read读文件与shell执行诊断命令两类工具。这一定权策略是刻意的审查者只需要看代码 跑验证命令不需要写文件从而在工具层面限制了审查过程中的副作用。Kiro 同时为该代理提供了一份 JSON 清单 .kiro/agents/swift-reviewer.json从源码结构看这是 Kiro 代理定义的双格式表示JSON 中allowedTools为[fs_read, shell]tools为[builtin]mcpServers与hooks均为空对象prompt字段则完整内嵌了与 Markdown 版本逐字相同的系统提示词。两份文件描述同一代理便于不同加载机制消费。调用流程先跑验证再谈审查文档正文开头定义了代理被调用时的 5 步标准动作运行swift build、swiftlint lint --quiet如已安装和swift test——任何一项失败就立即停止并报告不进入逐行审查运行git diff HEAD~1 -- *.swift查看最近一次提交的 Swift 文件变更PR 场景改用git diff main...HEAD -- *.swift审查范围锁定为被修改的.swift文件而不是全量代码若项目有 CI 或合并要求审查默认假设 CI 为绿色、合并冲突已解决如果 diff 本身暗示 CI 可能失败例如测试改动与实现不匹配需要明确指出开始按审查标准逐项检查。这套流程体现了一个务实的审查经济学构建与测试失败时代码级的风格问题毫无意义所以第一步是硬闸门hard gate第二步用git diff限定审查面避免 AI 审查常见的全库漫游、泛泛而谈问题。分层审查标准文档将审查项组织为 CRITICAL → HIGH → MEDIUM 三个严重度层级共 8 个专项。以下完整继承原文标准并逐条给出判定依据与仓库佐证。CRITICAL - Safety安全任何一条命中即触发 Block审查项判定与整改建议强制解包生产代码路径中的value!——改用guard let、if let或??强制 try无合理理由的try!——改用do/catch或以throws向上传播强制转换未做前置类型检查的as!——改用as?配合条件绑定硬编码密钥源码中出现 API key、密码、token——改用 Keychain 或环境变量UserDefaults 存敏感数据敏感数据写入UserDefaults——改用 Keychain ServicesSQL/命令注入在查询语句或 shell 命令中使用字符串插值路径穿越用户可控路径未经校验不安全反序列化解码不可信数据时没有校验或大小限制其中硬编码密钥与UserDefaults 存密钥两条在仓库的 Swift 安全规则 rules/swift/security.md 中有更完整的展开该文件声明敏感数据token、密码、密钥必须走 Keychain Services构建期密钥用环境变量或.xcconfig并给出环境变量取值的示例代码let apiKey ProcessInfo.processInfo.environment[API_KEY] guard let apiKey, !apiKey.isEmpty else { fatalError(API_KEY not configured) }同时该文件还强调了传输安全ATS 默认强制开启、关键端点做证书固定与输入校验外部来源数据——API、深链、粘贴板——须先校验再处理。这些正是审查代理在实际执行 CRITICAL - Safety 检查时可以直接对标的规则文件。CRITICAL - Error Handling错误处理审查项说明被吞掉的错误空catch {}块或用try?丢弃有意义的错误缺少错误上下文直接重新抛出而没有包装成领域特定错误fatalError()用于可恢复条件调用方本可以处理的错误应使用throwassert用于必要不变式assert在 release 构建中会被剥离——应改用precondition第 4 条值得展开Swift 中assert只在调试构建生效若某个不变式在 release 下也必须成立例如数组索引合法性用assert会导致检查在发布版中静默消失。precondition在调试与发布构建中都会强制检查因此必要不变式必须用后者。HIGH - Concurrency并发Swift Concurrency 是当前 Swift 项目缺陷最集中的区域文档列出 6 条数据竞争可变共享状态没有 actor 隔离或同步手段Sendable违规非Sendable类型跨越隔离边界传递阻塞主 actor在MainActor上执行同步 I/O 或Thread.sleep无取消的非结构化Task {}fire-and-forget 任务泄漏actor 重入问题跨await挂起点时对状态一致性做了错误假设——actor 在await处挂起时允许其他任务进入读-改-写跨挂起点时可能观察到中间状态缺失MainActorUI 更新在主 actor 之外执行。HIGH - Memory Management内存管理ARC 引用计数模型下的四个经典陷阱强引用循环长生命周期上下文中闭包强捕获self——使用[weak self]Delegate 强引用delegate 属性未声明weak形成保留环逃逸闭包缺少捕获列表没有显式声明捕获语义大值类型拷贝过大的struct在每次赋值时整体复制。HIGH - Code Quality代码质量超大函数超过 50 行深层嵌套超过 4 层演进枚举上的通配 switchdefault:会掩盖未来新增的 case——应使用unknown default它会提示开发者该 default 分支可能不再必要死代码未使用的函数、import 或变量。HIGH - Protocol-Oriented Design协议导向设计这是该代理区别于通用代码审查器的核心特色frontmatter 中 protocol-oriented design, value semantics 即指向此节协议已足够却用类继承优先协议遵循 默认扩展实现复用Any/AnyObject滥用改用带约束的泛型或any Protocol/some Protocol缺失协议遵循类型本应遵循Equatable、Hashable、Codable或Sendable却没有。MEDIUM - Performance性能热路径上的不必要分配在紧凑循环内创建对象缺少reserveCapacity已知最终容量却逐元素增长数组循环内字符串插值重复触发String分配N1 查询在循环内发起数据库或网络调用。MEDIUM - Best Practices最佳实践可用let时用了var优先不可变绑定可用struct时用了class数据模型优先值类型生产代码中的print()应使用os.Logger或结构化日志缺失访问控制类型默认为internal而本应是private公开 API 无文档public成员缺少///文档注释魔法数字/字符串应使用命名常量或枚举。诊断命令集文档给出了一组可直接复制执行的诊断命令swift build if command -v swiftlint /dev/null 21; then swiftlint lint --quiet; else echo [info] swiftlint not installed; fi swift test swift package resolve要点解读swift build与swift test是 SwiftPM 项目的标准构建/测试入口覆盖所有 SPM 可构建目标swiftlint一行使用了command -v做存在性探测——代理不能假设开发者机器上装了 SwiftLint因此可选工具都采用有则运行、无则降级提示的写法swift package resolve重新解析依赖图用于排除依赖声明与 lockfile 不一致这类导致本地构建偶发失败的问题。审批决策标准审查结论收敛为三档Approve通过无 CRITICAL 或 HIGH 问题Warning警告仅存在 MEDIUM 问题——代码可以合并但列出改进建议Block阻断发现任一 CRITICAL 或 HIGH 问题。文档结尾还给出审查心态基准Would this code pass review at a top Swift shop or well-maintained open-source project?——即所有规则最终服从同一个判定代码能否经受住头部 Swift 团队或高质量开源项目的评审。纵深对照Claude Code 版本代理的增量条款仓库中同名代理 agents/swift-reviewer.md 是面向 Claude Code 的版本frontmatter 为tools: Read, Grep, Glob, Bash并声明model: sonnet。两者共享同一套五级调用流程与审查骨架但 Claude Code 版本在多条目上更严格可以作为 Kiro 版本的增强参考安全层新增ATS disabled无合理理由关闭 App Transport Security 视为 CRITICAL错误处理层新增precondition/fatalError用于库代码precondition在调试与发布构建中都会崩溃fatalError无条件崩溃公开 API 边界上应改用throw代码质量层新增非穷尽匹配需要显式处理时却写了兜底分支协议设计层新增存在类型优于泛型参数可用some Protocol或泛型约束时却用了any Protocol性能层新增不必要的objc桥接纯 Swift 足够时避免 Swift 到 Objective-C 的过桥开销最佳实践层新增SwiftLint 警告未处理无理由的// swiftlint:disable抑制与字符串化 API用原始字符串表达本应建模为枚举的值诊断命令新增swift-format lint -r .的可选探测同样先command -v判存再执行并截取前 30 行输出交叉引用不同Kiro 版本引用技能swift-actor-persistence、swift-protocol-di-testingClaude Code 版本则引用规则文件swift/coding-style、swift/patterns、swift/security、swift/testing对应仓库 rules/swift/ 目录下的同名.md文件以及技能swift-concurrency-6-2、swiftui-patterns、swift-protocol-di-testing。从源码结构看这种同一专家、多 Harness 变体是 ECC 的通用组织方式核心审查逻辑只维护一份按宿主工具Kiro / Claude Code在 frontmatter 的工具体系、安全基线Claude Code 版本开头有 Prompt Defense Baseline 反提示注入条款和诊断命令上做适配。配套技能审查标准背后的两个 Swift 模式文档末行将swift-actor-persistence与swift-protocol-di-testing两个技能作为详细模式与规则的延伸引用二者恰好对应审查标准中并发与代码质量/协议设计两条 HIGH 线的最佳实践落地。swift-actor-persistence用 actor 消除数据竞争技能 skills/swift-actor-persistence/SKILL.md 展示了一个通用的 actor 仓库模式内存缓存 文件持久化由编译器强制串行化访问直接消除数据竞争审查项。核心结构如下public actor LocalRepositoryT: Codable Identifiable where T.ID String { private var cache: [String: T] [:] private let fileURL: URL public init(directory: URL .documentsDirectory, filename: String data.json) { self.fileURL directory.appendingPathComponent(filename) // Synchronous load during init (actor isolation not yet active) self.cache Self.loadSynchronously(from: fileURL) } public func save(_ item: T) throws { cache[item.id] item try persistToFile() } public func find(by id: String) - T? { cache[id] } private func persistToFile() throws { let data try JSONEncoder().encode(Array(cache.values)) try data.write(to: fileURL, options: .atomic) } // ... }其关键设计决策技能内以表格形式给出包括用 actor 而非类 锁获得编译器强制的线程安全字典按 ID 索引实现 O(1) 查找泛型约束Codable Identifiable使其可复用于任意模型文件写入使用.atomic防止崩溃时出现半写文件。调用侧因为 actor 隔离天然全异步let question await repository.find(by: q-001)。对照审查标准可见可变共享状态无 actor 隔离非Sendable类型跨边界这类 HIGH 项在此模式下的标准答案就是把状态收进 actor、把跨边界数据类型约束为Sendable。技能同时列出了反模式清单例如新并发代码用DispatchQueue/NSLock、用nonisolated绕开 actor 隔离等与审查代理fire-and-forget 任务泄漏等条款形成呼应。swift-protocol-di-testing协议化依赖注入技能 skills/swift-protocol-di-testing/SKILL.md 回答另一个审查关切如何让文件/网络/外部 API相关的 Swift 代码可测试。其模式分五步定义小而聚焦的Sendable协议例如public protocol FileAccessorProviding: Sendable { func read(from url: URL) throws - Data func write(_ data: Data, to url: URL) throws func fileExists(at url: URL) - Bool }提供生产实现如DefaultFileAccessor封装Data(contentsOf:)与原子写入编写可注入错误的 mockreadError/writeError属性用于模拟失败路径通过带默认值的参数注入——生产代码走默认实现测试只需注入 mockpublic actor SyncManager { public init( fileSystem: FileSystemProviding DefaultFileSystemProvider(), fileAccessor: FileAccessorProviding DefaultFileAccessor() ) { /* ... */ } }用 Swift Testing 框架断言错误路径例如await #expect(throws: SyncError.containerNotAvailable) { try await manager.sync() }。技能的仅 mock 边界不 mock 内部类型原则恰好是审查标准中协议滥用Any/AnyObject、过度抽象条款的反面锚点抽象应发生在外部依赖边界而不是渗透进每个内部类型。如何应用这套审查体系结合以上各部分在 Swift 项目中使用该代理的完整路径是将 .kiro/agents/swift-reviewer.md 放入项目的.kiro/agents/目录Kiro 会将其注册为可调用代理配套 JSON 清单 swift-reviewer.json 一并存在以兼容清单式加载在每次 Swift 变更提交或 PR后调用swift-reviewer它会按构建/测试闸门 → diff 定位 → 分层审查 → 三档结论的流程给出结构化结果对审查中反复命中的模式类问题按文档末行引用的技能深入修复线程安全问题参考 swift-actor-persistence 的 actor 仓库模式可测试性问题参考 swift-protocol-di-testing 的边界协议注入模式项目级规则可进一步与 rules/swift/security.md、rules/swift/patterns.md 等规则文件对齐使代理的审查口径与团队规范文件保持同一来源。这套设计的可取之处在于把资深 Swift 审查者的隐性经验显式化为可版本化、可跨项目复用的资产frontmatter 限定工具与角色调用流程保证审查有闸门、有边界分层标准保证结论可判定Approve/Warning/Block配套技能保证每个审查项都有对应的正模式可依。适用前提需要说明该代理面向 Swift Package Manager 可构建项目诊断命令基于swift build/swift testSwiftLint 与 swift-format 均为可选依赖缺失时自动降级为提示而非失败。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ECC swift-reviewer：面向 Kiro 的分层 Swift 代码审查代理设计与全量审查标准
ECC swift-reviewer面向 Kiro 的分层 Swift 代码审查代理设计与全量审查标准【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC本篇指南以 ECC 仓库中 Kiro 代理定义文件 .kiro/agents/swift-reviewer.md 为主体完整解析这位资深 Swift 代码审查者的调用流程、CRITICAL/HIGH/MEDIUM 三级审查标准、诊断命令集与审批决策规则并结合仓库中同名的 Claude Code 版本代理 agents/swift-reviewer.md、配套技能 skills/swift-actor-persistence/SKILL.md、skills/swift-protocol-di-testing/SKILL.md 以及 rules/swift/security.md 做源码级佐证。读完后你将掌握一套可直接落地到 Swift 项目的 AI 审查流程从swift build/swiftlint/swift test前置检查到逐条对齐安全、错误处理、并发、内存、协议导向设计的审查清单再到 Approve/Warning/Block 的审批判定。代理定位与配置.kiro/agents/swift-reviewer.md采用 Kiro 的 Markdown 代理定义格式YAML frontmatter 声明元信息正文即注入给模型的系统提示词。其 frontmatter 完整内容如下name: swift-reviewer description: Expert Swift code reviewer specializing in protocol-oriented design, value semantics, ARC memory management, Swift Concurrency, and idiomatic patterns. Use for all Swift code changes. MUST BE USED for Swift projects. allowedTools: - read - shell各字段的作用可以直接从配置本身读出name代理在 Kiro 中的注册名用于在会话中按名称调用description触发描述。特别值得注意的是其中的强制性措辞——Use for all Swift code changes. MUST BE USED for Swift projects.即凡是涉及 Swift 代码变更的场景都应路由到该代理这是 ECC 代理体系中典型的单用途专家代理命名法仓库agents/目录下还有python-reviewer、rust-reviewer等同构定义allowedTools只授予read读文件与shell执行诊断命令两类工具。这一定权策略是刻意的审查者只需要看代码 跑验证命令不需要写文件从而在工具层面限制了审查过程中的副作用。Kiro 同时为该代理提供了一份 JSON 清单 .kiro/agents/swift-reviewer.json从源码结构看这是 Kiro 代理定义的双格式表示JSON 中allowedTools为[fs_read, shell]tools为[builtin]mcpServers与hooks均为空对象prompt字段则完整内嵌了与 Markdown 版本逐字相同的系统提示词。两份文件描述同一代理便于不同加载机制消费。调用流程先跑验证再谈审查文档正文开头定义了代理被调用时的 5 步标准动作运行swift build、swiftlint lint --quiet如已安装和swift test——任何一项失败就立即停止并报告不进入逐行审查运行git diff HEAD~1 -- *.swift查看最近一次提交的 Swift 文件变更PR 场景改用git diff main...HEAD -- *.swift审查范围锁定为被修改的.swift文件而不是全量代码若项目有 CI 或合并要求审查默认假设 CI 为绿色、合并冲突已解决如果 diff 本身暗示 CI 可能失败例如测试改动与实现不匹配需要明确指出开始按审查标准逐项检查。这套流程体现了一个务实的审查经济学构建与测试失败时代码级的风格问题毫无意义所以第一步是硬闸门hard gate第二步用git diff限定审查面避免 AI 审查常见的全库漫游、泛泛而谈问题。分层审查标准文档将审查项组织为 CRITICAL → HIGH → MEDIUM 三个严重度层级共 8 个专项。以下完整继承原文标准并逐条给出判定依据与仓库佐证。CRITICAL - Safety安全任何一条命中即触发 Block审查项判定与整改建议强制解包生产代码路径中的value!——改用guard let、if let或??强制 try无合理理由的try!——改用do/catch或以throws向上传播强制转换未做前置类型检查的as!——改用as?配合条件绑定硬编码密钥源码中出现 API key、密码、token——改用 Keychain 或环境变量UserDefaults 存敏感数据敏感数据写入UserDefaults——改用 Keychain ServicesSQL/命令注入在查询语句或 shell 命令中使用字符串插值路径穿越用户可控路径未经校验不安全反序列化解码不可信数据时没有校验或大小限制其中硬编码密钥与UserDefaults 存密钥两条在仓库的 Swift 安全规则 rules/swift/security.md 中有更完整的展开该文件声明敏感数据token、密码、密钥必须走 Keychain Services构建期密钥用环境变量或.xcconfig并给出环境变量取值的示例代码let apiKey ProcessInfo.processInfo.environment[API_KEY] guard let apiKey, !apiKey.isEmpty else { fatalError(API_KEY not configured) }同时该文件还强调了传输安全ATS 默认强制开启、关键端点做证书固定与输入校验外部来源数据——API、深链、粘贴板——须先校验再处理。这些正是审查代理在实际执行 CRITICAL - Safety 检查时可以直接对标的规则文件。CRITICAL - Error Handling错误处理审查项说明被吞掉的错误空catch {}块或用try?丢弃有意义的错误缺少错误上下文直接重新抛出而没有包装成领域特定错误fatalError()用于可恢复条件调用方本可以处理的错误应使用throwassert用于必要不变式assert在 release 构建中会被剥离——应改用precondition第 4 条值得展开Swift 中assert只在调试构建生效若某个不变式在 release 下也必须成立例如数组索引合法性用assert会导致检查在发布版中静默消失。precondition在调试与发布构建中都会强制检查因此必要不变式必须用后者。HIGH - Concurrency并发Swift Concurrency 是当前 Swift 项目缺陷最集中的区域文档列出 6 条数据竞争可变共享状态没有 actor 隔离或同步手段Sendable违规非Sendable类型跨越隔离边界传递阻塞主 actor在MainActor上执行同步 I/O 或Thread.sleep无取消的非结构化Task {}fire-and-forget 任务泄漏actor 重入问题跨await挂起点时对状态一致性做了错误假设——actor 在await处挂起时允许其他任务进入读-改-写跨挂起点时可能观察到中间状态缺失MainActorUI 更新在主 actor 之外执行。HIGH - Memory Management内存管理ARC 引用计数模型下的四个经典陷阱强引用循环长生命周期上下文中闭包强捕获self——使用[weak self]Delegate 强引用delegate 属性未声明weak形成保留环逃逸闭包缺少捕获列表没有显式声明捕获语义大值类型拷贝过大的struct在每次赋值时整体复制。HIGH - Code Quality代码质量超大函数超过 50 行深层嵌套超过 4 层演进枚举上的通配 switchdefault:会掩盖未来新增的 case——应使用unknown default它会提示开发者该 default 分支可能不再必要死代码未使用的函数、import 或变量。HIGH - Protocol-Oriented Design协议导向设计这是该代理区别于通用代码审查器的核心特色frontmatter 中 protocol-oriented design, value semantics 即指向此节协议已足够却用类继承优先协议遵循 默认扩展实现复用Any/AnyObject滥用改用带约束的泛型或any Protocol/some Protocol缺失协议遵循类型本应遵循Equatable、Hashable、Codable或Sendable却没有。MEDIUM - Performance性能热路径上的不必要分配在紧凑循环内创建对象缺少reserveCapacity已知最终容量却逐元素增长数组循环内字符串插值重复触发String分配N1 查询在循环内发起数据库或网络调用。MEDIUM - Best Practices最佳实践可用let时用了var优先不可变绑定可用struct时用了class数据模型优先值类型生产代码中的print()应使用os.Logger或结构化日志缺失访问控制类型默认为internal而本应是private公开 API 无文档public成员缺少///文档注释魔法数字/字符串应使用命名常量或枚举。诊断命令集文档给出了一组可直接复制执行的诊断命令swift build if command -v swiftlint /dev/null 21; then swiftlint lint --quiet; else echo [info] swiftlint not installed; fi swift test swift package resolve要点解读swift build与swift test是 SwiftPM 项目的标准构建/测试入口覆盖所有 SPM 可构建目标swiftlint一行使用了command -v做存在性探测——代理不能假设开发者机器上装了 SwiftLint因此可选工具都采用有则运行、无则降级提示的写法swift package resolve重新解析依赖图用于排除依赖声明与 lockfile 不一致这类导致本地构建偶发失败的问题。审批决策标准审查结论收敛为三档Approve通过无 CRITICAL 或 HIGH 问题Warning警告仅存在 MEDIUM 问题——代码可以合并但列出改进建议Block阻断发现任一 CRITICAL 或 HIGH 问题。文档结尾还给出审查心态基准Would this code pass review at a top Swift shop or well-maintained open-source project?——即所有规则最终服从同一个判定代码能否经受住头部 Swift 团队或高质量开源项目的评审。纵深对照Claude Code 版本代理的增量条款仓库中同名代理 agents/swift-reviewer.md 是面向 Claude Code 的版本frontmatter 为tools: Read, Grep, Glob, Bash并声明model: sonnet。两者共享同一套五级调用流程与审查骨架但 Claude Code 版本在多条目上更严格可以作为 Kiro 版本的增强参考安全层新增ATS disabled无合理理由关闭 App Transport Security 视为 CRITICAL错误处理层新增precondition/fatalError用于库代码precondition在调试与发布构建中都会崩溃fatalError无条件崩溃公开 API 边界上应改用throw代码质量层新增非穷尽匹配需要显式处理时却写了兜底分支协议设计层新增存在类型优于泛型参数可用some Protocol或泛型约束时却用了any Protocol性能层新增不必要的objc桥接纯 Swift 足够时避免 Swift 到 Objective-C 的过桥开销最佳实践层新增SwiftLint 警告未处理无理由的// swiftlint:disable抑制与字符串化 API用原始字符串表达本应建模为枚举的值诊断命令新增swift-format lint -r .的可选探测同样先command -v判存再执行并截取前 30 行输出交叉引用不同Kiro 版本引用技能swift-actor-persistence、swift-protocol-di-testingClaude Code 版本则引用规则文件swift/coding-style、swift/patterns、swift/security、swift/testing对应仓库 rules/swift/ 目录下的同名.md文件以及技能swift-concurrency-6-2、swiftui-patterns、swift-protocol-di-testing。从源码结构看这种同一专家、多 Harness 变体是 ECC 的通用组织方式核心审查逻辑只维护一份按宿主工具Kiro / Claude Code在 frontmatter 的工具体系、安全基线Claude Code 版本开头有 Prompt Defense Baseline 反提示注入条款和诊断命令上做适配。配套技能审查标准背后的两个 Swift 模式文档末行将swift-actor-persistence与swift-protocol-di-testing两个技能作为详细模式与规则的延伸引用二者恰好对应审查标准中并发与代码质量/协议设计两条 HIGH 线的最佳实践落地。swift-actor-persistence用 actor 消除数据竞争技能 skills/swift-actor-persistence/SKILL.md 展示了一个通用的 actor 仓库模式内存缓存 文件持久化由编译器强制串行化访问直接消除数据竞争审查项。核心结构如下public actor LocalRepositoryT: Codable Identifiable where T.ID String { private var cache: [String: T] [:] private let fileURL: URL public init(directory: URL .documentsDirectory, filename: String data.json) { self.fileURL directory.appendingPathComponent(filename) // Synchronous load during init (actor isolation not yet active) self.cache Self.loadSynchronously(from: fileURL) } public func save(_ item: T) throws { cache[item.id] item try persistToFile() } public func find(by id: String) - T? { cache[id] } private func persistToFile() throws { let data try JSONEncoder().encode(Array(cache.values)) try data.write(to: fileURL, options: .atomic) } // ... }其关键设计决策技能内以表格形式给出包括用 actor 而非类 锁获得编译器强制的线程安全字典按 ID 索引实现 O(1) 查找泛型约束Codable Identifiable使其可复用于任意模型文件写入使用.atomic防止崩溃时出现半写文件。调用侧因为 actor 隔离天然全异步let question await repository.find(by: q-001)。对照审查标准可见可变共享状态无 actor 隔离非Sendable类型跨边界这类 HIGH 项在此模式下的标准答案就是把状态收进 actor、把跨边界数据类型约束为Sendable。技能同时列出了反模式清单例如新并发代码用DispatchQueue/NSLock、用nonisolated绕开 actor 隔离等与审查代理fire-and-forget 任务泄漏等条款形成呼应。swift-protocol-di-testing协议化依赖注入技能 skills/swift-protocol-di-testing/SKILL.md 回答另一个审查关切如何让文件/网络/外部 API相关的 Swift 代码可测试。其模式分五步定义小而聚焦的Sendable协议例如public protocol FileAccessorProviding: Sendable { func read(from url: URL) throws - Data func write(_ data: Data, to url: URL) throws func fileExists(at url: URL) - Bool }提供生产实现如DefaultFileAccessor封装Data(contentsOf:)与原子写入编写可注入错误的 mockreadError/writeError属性用于模拟失败路径通过带默认值的参数注入——生产代码走默认实现测试只需注入 mockpublic actor SyncManager { public init( fileSystem: FileSystemProviding DefaultFileSystemProvider(), fileAccessor: FileAccessorProviding DefaultFileAccessor() ) { /* ... */ } }用 Swift Testing 框架断言错误路径例如await #expect(throws: SyncError.containerNotAvailable) { try await manager.sync() }。技能的仅 mock 边界不 mock 内部类型原则恰好是审查标准中协议滥用Any/AnyObject、过度抽象条款的反面锚点抽象应发生在外部依赖边界而不是渗透进每个内部类型。如何应用这套审查体系结合以上各部分在 Swift 项目中使用该代理的完整路径是将 .kiro/agents/swift-reviewer.md 放入项目的.kiro/agents/目录Kiro 会将其注册为可调用代理配套 JSON 清单 swift-reviewer.json 一并存在以兼容清单式加载在每次 Swift 变更提交或 PR后调用swift-reviewer它会按构建/测试闸门 → diff 定位 → 分层审查 → 三档结论的流程给出结构化结果对审查中反复命中的模式类问题按文档末行引用的技能深入修复线程安全问题参考 swift-actor-persistence 的 actor 仓库模式可测试性问题参考 swift-protocol-di-testing 的边界协议注入模式项目级规则可进一步与 rules/swift/security.md、rules/swift/patterns.md 等规则文件对齐使代理的审查口径与团队规范文件保持同一来源。这套设计的可取之处在于把资深 Swift 审查者的隐性经验显式化为可版本化、可跨项目复用的资产frontmatter 限定工具与角色调用流程保证审查有闸门、有边界分层标准保证结论可判定Approve/Warning/Block配套技能保证每个审查项都有对应的正模式可依。适用前提需要说明该代理面向 Swift Package Manager 可构建项目诊断命令基于swift build/swift testSwiftLint 与 swift-format 均为可选依赖缺失时自动降级为提示而非失败。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考