| 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. |
iOS 需求实现
核心原则
先读懂需求，再理解现有代码，搞清关联后再动手，改完必须全面审查。
需求不等于"新建"。大多数需求是在现有功能上新增、修改或扩展。在动手之前，必须先回答：
- 需求要什么？ — 最终用户在什么场景下得到什么结果
- 现有代码什么样？ — 相关功能现在是怎么实现的
- 改动影响什么？ — 新代码和现有代码的关联关系是什么
- 怎么验收？ — 验收标准是否明确且可验证
绝对禁止
- 需求没读完就开始写代码
- 不理解现有代码的设计意图就直接修改或新增
- 不分析与现有功能的关联就开始实现
- 改完不验证对其他功能的影响就提交 PR
需求类型速判
| 类型 | 重点关注 | 风险点 |
|---|
| 全新功能 | 模块设计、技术选型 | 与现有架构风格不一致 |
| 功能增强 | 现有设计意图、扩展点 | 破坏现有逻辑 |
| 功能修改 | 旧行为依赖方、新旧差异 | 依赖旧行为的地方异常 |
| 交互优化 | 设计稿细节、动画/手势 | 影响无障碍访问 |
| 数据/接口调整 | 新旧结构差异、迁移 | 旧版本兼容性 |
复杂度速判
在开始五阶段流程之前，先判断需求复杂度，选择合适的流程路径：
| 级别 | 特征 | 示例 | 流程路径 |
|---|
| 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.md
SwiftUI 现代模式见 references/swiftui-patterns.md
UIKit 实现模式见 references/uikit-patterns.md
网络层模式见 references/networking-patterns.md
持久化模式见 references/persistence-patterns.md
测试策略见 references/testing-strategy.md
🚦 门控输出： 可编译运行的代码 + 通过的单元测试。代码不能编译或测试失败则不通过。
阶段五：全面审查与影响评估
目标： 确保实现正确、不引入新问题、不影响现有功能。
代码自审
影响范围验证（五层）
- 直接功能 — 新增/修改功能按需求预期工作？所有状态变体正确？
- 同页面 — 同页面其他功能正常？布局和性能无影响？
- 关联页面 — 数据流上下游正常？导航前后正确？状态同步及时？
- 公共代码 — 全局搜索所有调用方，逐一验证修改后的行为
- 全量回归 — 重大改动时运行完整测试套件
多维度验证
- 设备/系统：最低版本 + 最新版本 + 不同屏幕尺寸
- 显示模式：Light/Dark Mode + Dynamic Type
- 网络环境：正常/弱网/无网络（如涉及）
PR 提交
标题：feat: [一句话描述] 或 enhance: [一句话描述]
描述包含：需求描述、需求类型、实现方案、改动范围、影响分析、测试结果、截图
🚦 门控输出： 自审清单全部勾选 + 五层影响验证通过 + PR 已提交。任一项未通过则不算完成。
Topic Router
| 话题 | 引用文件 |
|---|
| 需求类型判断、信息提取、设计稿/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 |
| 引入与项目不一致的风格 | 遵循项目现有风格 |
| 不写测试就提交 | 至少覆盖核心逻辑 |
| "能跑了"就提测 | 对照验证清单逐项确认 |
完成清单
与其他 Skill 的协作
- ios-issue-fix：实现过程中发现 Bug 时，切换到 Issue 修复流程
- code-review：PR 提交后的代码审查
