先规划再编码

要解决什么问题

在 iOS 仓库里，Agent 很容易一上来就改 Swift 文件、动 .pbxproj、跑会污染 DerivedData 的构建脚本，结果方案没对齐架构文档和 harness，验证命令也是临时拼凑的。本技能把「规划」和「执行」拆开，并要求计划锚定在仓库真实的 Xcode scheme、模拟器/真机约束以及文档化的验证流程上。

技能如何工作

工作流按三种意图使用，对应三个阶段：

1. 仅规划（Plan Only）：用户要求先定方案时，禁止创建/修改/删除文件、跑迁移或提交。先读 AGENTS.md、iOS 架构与 harness 文档、执行计划与 Maestro 说明；只用只读手段（如 rg、git diff --stat、xcodebuild -list、文件读取）。输出应包含推荐实现路径、影响面、文件归属、已知的验证命令（如具体 xcodebuild、Maestro flow、项目 harness 脚本），以及风险与开放问题；缺命令时写清执行阶段要查的路径，而不是编造。
2. 多 Agent 拆分评估：在用户询问能否并行时，按共享文件（VC、SwiftUI、coordinator、model、工程文件、资源与本地化等）、依赖顺序（API/模型先于 UI、路由先于页面流）、验证瓶颈（单模拟器、单 scheme、共享 DerivedData、长 UI flow）和合并风险（.pbxproj、快照、storyboard 等）给出建议。紧耦合或易冲突时建议单 Agent；仅当职责与写权限清晰disjoint 时才建议多 Agent，并说明集成顺序与必须串行的部分。评估阶段不自动拉起子 Agent。
3. 批准后执行：仅在用户明确同意「按当前方案开始实现」后改代码。若线程里没有成文计划，先复述并确认再动手。模糊的状态询问、可行性讨论不算批准。执行时遵循仓库本地规则，按需使用子 Agent且每个任务边界清晰；跑仓库规定的验证门禁，失败时记录确切命令与产物。

Harness 取向：以仓库文档中的 harness 为准，优先既有验证脚本与 XcodeBuildMCP/项目封装的 xcodebuild；不为了省事加假启动路由、假 Store 或测试专用运行时路径。Maestro 上优先 launchApp.permissions / setPermissions 预置权限，而非在 smoke flow 里点系统弹窗。

适用边界

• 面向受控 iOS 开发场景，非通用「任何语言先写设计文档」模板。
• 阶段一与拆分评估默认只读；任何会改工程或 DerivedData 的操作都要等用户批准。
• 多 Agent 只是规划结论；真正并行实现需要用户既问拆分又批准执行，且计划里已写明分工。