菜单
Guides iOS feature implementation through a five-phase methodology from requirement analysis to final review. Use when implementing new features, enhancing existing features, or adapting to API changes in iOS projects using Swift, SwiftUI, or UIKit.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | ios-feature-impl |
| description | Guides iOS feature implementation through a five-phase methodology from requirement analysis to final review. Use when implementing new features, enhancing existing features, or adapting to API changes in iOS projects using Swift, SwiftUI, or UIKit. |
先读懂需求，再理解现有代码，搞清关联后再动手，改完必须全面审查。
需求不等于"新建"。大多数需求是在现有功能上新增、修改或扩展。在动手之前，必须先回答：
| 类型 | 重点关注 | 风险点 |
|---|---|---|
| 全新功能 | 模块设计、技术选型 | 与现有架构风格不一致 |
| 功能增强 | 现有设计意图、扩展点 | 破坏现有逻辑 |
| 功能修改 | 旧行为依赖方、新旧差异 | 依赖旧行为的地方异常 |
| 交互优化 | 设计稿细节、动画/手势 | 影响无障碍访问 |
| 数据/接口调整 | 新旧结构差异、迁移 | 旧版本兼容性 |
在开始五阶段流程之前，先判断需求复杂度，选择合适的流程路径：
| 级别 | 特征 | 示例 | 流程路径 |
|---|---|---|---|
| S（小） | 改动 ≤ 3 个文件，无新架构决策，无跨模块影响 | 改文案、调颜色、加简单字段、修小 Bug | 阶段一 → 阶段四 → 阶段五 |
| M（中） | 改动 4-10 个文件，有限的跨模块影响，复用现有架构 | 新增列表页、新增表单字段组、适配 API 变更 | 完整五阶段 |
| L（大） | 改动 > 10 个文件，需新架构决策，跨多模块影响 | 全新功能模块、重大交互改版、底层模型重构 | 完整五阶段 + 方案评审 |
S 级简化说明： 跳过阶段二（上下文分析）和阶段三（关联分析），但仍需在阶段四编码时确认现有代码风格，在阶段五做基本的自审和影响验证。若实现过程中发现影响超出预期，立即升级为 M 级。
目标： 准确理解"要做什么"和"做到什么程度"。
判断需求类型 → 提取需求信息 → 审阅设计稿 → 审阅 API → 输出需求理解卡片和疑问清单。
疑问清单必须在写代码前关闭。特别是增量需求，"这个改动要不要影响已有功能"必须提前确认。
详细流程和模板见
references/requirement-analysis.md
🚦 门控输出： 需求理解卡片 + 疑问清单（全部关闭）。未通过则不进入下一阶段。
目标： 理解现有代码的设计意图和实现现状，找到正确的修改/扩展位置。
定位相关代码 → 逐层理解设计意图（View/ViewModel/数据层/通用模式） → 阅读 Git 历史 → 阅读现有测试 → 输出上下文分析摘要。
如果写不出"现有设计意图"，说明代码还没读懂，不要进入下一步。
详细流程和模板见
references/context-analysis.md
🚦 门控输出： 上下文分析摘要（含架构模式、相关文件、设计意图、扩展点）。写不出"现有设计意图"则不通过。
目标： 理清新需求与现有功能的所有关联关系，预判实现对其他地方的影响。
梳理关联关系（数据/UI/状态/导航/业务规则） → 评估影响范围（直接/间接/潜在） → iOS 平台检查 → 输出关联分析与实现方案。
如果关联分析发现改动波及面过大，暂停并与团队讨论方案。
详细流程和模板见
references/impact-analysis.md
🚦 门控输出： 关联分析文档 + 实现方案（含改动点清单、新增文件、需验证的关联页面）。波及面过大则暂停讨论。
目标： 按方案逐步实现，遵循项目现有约定，每步可验证。
确认编码前检查清单 → 按自底向上顺序实现 → 遵循编码原则 → 编写测试。
编码规范和模板见
references/coding-standards.mdSwiftUI 现代模式见references/swiftui-patterns.mdUIKit 实现模式见references/uikit-patterns.md网络层模式见references/networking-patterns.md持久化模式见references/persistence-patterns.md测试策略见references/testing-strategy.md
🚦 门控输出： 可编译运行的代码 + 通过的单元测试。代码不能编译或测试失败则不通过。
目标： 确保实现正确、不引入新问题、不影响现有功能。
[weak self] 正确使用？UI 操作在主线程？标题：feat: [一句话描述] 或 enhance: [一句话描述]
描述包含：需求描述、需求类型、实现方案、改动范围、影响分析、测试结果、截图
🚦 门控输出： 自审清单全部勾选 + 五层影响验证通过 + PR 已提交。任一项未通过则不算完成。
| 话题 | 引用文件 |
|---|---|
| 需求类型判断、信息提取、设计稿/API审阅 | references/requirement-analysis.md |
| 定位代码、理解设计意图、Git历史 | references/context-analysis.md |
| 关联关系、影响范围、平台检查 | references/impact-analysis.md |
| 编码原则、Swift 6 并发、代码模板 | references/coding-standards.md |
| SwiftUI 状态管理、导航、布局、性能 | references/swiftui-patterns.md |
| UIKit 视图构建 / Auto Layout / 混编 | references/uikit-patterns.md |
| API Service / Codable 模型 / 分页 / 网络错误处理 | references/networking-patterns.md |
| 持久化 / Core Data / SwiftData / Keychain / UserDefaults | references/persistence-patterns.md |
| 测试覆盖、Swift Testing、快照测试 | references/testing-strategy.md |
| 列表/表单/详情页/新页面/API适配/需求变更 | references/scenario-quickref.md |
| 违规行为 | 正确做法 |
|---|---|
| 需求没读完就动手 | 完成需求理解卡片 |
| 不看现有代码直接加 | 完成上下文分析 |
| 不分析关联就实现 | 完成关联分析 |
| 改了公共代码不验调用方 | 全局搜索逐一验证 |
| 需求 PR 中混入重构 | 分开提 PR |
| 引入与项目不一致的风格 | 遵循项目现有风格 |
| 不写测试就提交 | 至少覆盖核心逻辑 |
| "能跑了"就提测 | 对照验证清单逐项确认 |
Guides comprehensive iOS code review following a structured five-phase methodology. Use when reviewing iOS Pull Requests, Merge Requests, or peer code that involves Swift, Objective-C, SwiftUI, or UIKit.
Guides iOS issue diagnosis and fix through a five-phase methodology from understanding the issue to verified fix. Use when fixing bugs, crashes, UI anomalies, performance issues, or any unexpected behavior in iOS applications.
Guides iOS performance optimization through a systematic five-phase methodology from profiling to verification. Use when optimizing app launch time, reducing memory usage, improving rendering performance, reducing app size, or addressing any performance-related issues in iOS applications.
Guides iOS code refactoring through a systematic five-phase methodology that ensures behavioral equivalence throughout the process. Use when migrating from ObjC to Swift, UIKit to SwiftUI, refactoring architecture patterns, modularizing codebases, or cleaning up technical debt in iOS projects.
Guides iOS test creation through a systematic five-phase methodology from test strategy design to comprehensive coverage verification. Use when writing unit tests, UI tests, snapshot tests, or integration tests for iOS applications, or when establishing testing practices for existing codebases.