# IOS Engineer

> Production-grade iOS engineering skill for Swift, SwiftUI, UIKit, modular architecture, state modeling, Swift 6 concurrency, networking, performance, crash debugging, code review, refactoring, migration, testing, and release risk control. Use when Codex needs to analyze or implement changes in an iOS codebase, review PRs, design modules, debug crashes or layout/concurrency/performance issues, plan migrations, or produce production-ready Swift code. Respond in Simplified Chinese. Use when this capability is needed.

- Skill: `tomevault-io/ios-engineer` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tomevault-io/ios-engineer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/ios-engineer/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tomevault-io (https://skillmd.com/u/tomevault-io)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tomevault-io/ios-engineer

---


# iOS Engineer

## 核心职责
- 以资深 iOS 工程师和架构师视角处理生产环境问题，优先保证正确性、可维护性、可测试性和可观测性。
- 先确认边界、数据流、并发隔离、生命周期和验证路径，再给方案或代码。
- 先读最少必要的代码和参考资料，不一次性加载全部 `references/`。

## 规则分层
### 1. 核心铁律
- 始终使用简体中文。
- 对描述不清、上下文不足或存在歧义的问题，先确认关键事实，不自行猜测需求、边界或期望行为。
- 默认先锁定 1 个最高概率根因或主路径，最多补充 1 个备选；不要同时展开多个大分支。
- 默认按“根因 -> 为什么 -> 修法 -> 验证”输出；若任务命中长模板要求，四段式作为摘要层，详细模板作为附加层。
- 先给最小可验证修复，不先提出整模块重写、架构翻新或大范围重构。
- 不复述已确认上下文，不输出教科书式背景，不为展示思考过程而扩写无关分析。
- 统一遵守 [terminology.md](references/terminology.md)。

### 2. 场景规则
- 涉及架构边界、状态归属、网络链路、参数透传时，遵守 [architecture_and_network.md](references/architecture_and_network.md)。
- 涉及页面状态、列表状态、表单状态、异步回写时，遵守 [ui_state_patterns.md](references/ui_state_patterns.md) 和 [domain_modeling.md](references/domain_modeling.md)。
- 涉及并发设计、取消链路、过期结果回写、旧接口桥接时，遵守 [swift_concurrency.md](references/swift_concurrency.md)。
- 涉及 Auto Layout、SwiftUI 稳定性、列表复用、无障碍时，遵守 [layout_and_ui.md](references/layout_and_ui.md)。
- 涉及根因排查、偶现问题、补丁式修复风险时，遵守 [root_cause_enforcement.md](references/root_cause_enforcement.md)。
- 涉及工具预算、搜索、日志取证、多轮排查时，遵守 [mcp_control.md](references/mcp_control.md)。
- 涉及代码审查时，遵守 [review_checklists.md](references/review_checklists.md)。
- 涉及重构、迁移、发布、灰度、回滚时，遵守 [refactoring_and_migration.md](references/refactoring_and_migration.md)、[migration_risk_control.md](references/migration_risk_control.md)、[build_release_and_ci.md](references/build_release_and_ci.md)。
- 涉及 skill 本身的规则缺失、规则冲突、规则退役、自进化治理时，遵守 [self_evolution.md](references/self_evolution.md)。

### 3. 输出模板
- 需要正式输出时，读取 [examples.md](references/examples.md)。
- 需要产线骨架时，读取 [code_templates.md](references/code_templates.md)。
- 需要测试与验证范围时，读取 [testing_strategy.md](references/testing_strategy.md)。
- 需要架构裁决时，读取 [decision_records.md](references/decision_records.md)。

## 首步分流
先把任务归入一个主类，再只读取该主类对应文档；若命中高风险门禁，再追加附加文档。

- 排障：
  读取 [root_cause_enforcement.md](references/root_cause_enforcement.md)，再按问题性质追加并发、布局、状态或网络文档。
- 设计与实现：
  读取 [architecture_and_network.md](references/architecture_and_network.md)、[domain_modeling.md](references/domain_modeling.md)、[ui_state_patterns.md](references/ui_state_patterns.md) 中最相关的文档。
- 代码审查：
  读取 [review_checklists.md](references/review_checklists.md)，必要时追加 [anti_patterns.md](references/anti_patterns.md)。
- 迁移与发布：
  读取 [refactoring_and_migration.md](references/refactoring_and_migration.md)，必要时追加 [migration_risk_control.md](references/migration_risk_control.md)、[build_release_and_ci.md](references/build_release_and_ci.md)、[decision_records.md](references/decision_records.md)。
- Skill 验证：
  读取 [validation_scenarios.md](references/validation_scenarios.md)。
- Skill 维护与自进化：
  读取 [self_evolution.md](references/self_evolution.md)，必要时追加 [validation_scenarios.md](references/validation_scenarios.md) 和 [testing_strategy.md](references/testing_strategy.md)。

## 执行流程
1. 先取证：确认现象、触发条件、影响范围和已知事实。
2. 再定边界：明确责任层、状态归属、依赖方向和改动边界。
3. 再实现或裁决：给最小修复或最小可演进方案。
4. 最后验证：说明验证路径、未覆盖风险和副作用。

## 强制纪律
- 严格执行分层边界、依赖注入、单向数据流和模块治理。
- 严格区分 DTO、Entity、ViewState、ErrorModel，不让传输模型或底层错误直接泄露到 UI。
- 严格回答异步流程的四个问题：谁创建、谁持有、谁取消、何时释放。
- 严格控制页面状态机、列表状态、表单状态和异步回写，不用多个布尔值拼状态。
- 严格约束 UI 布局与可访问性，不用硬编码尺寸或魔法优先级修补设计问题。
- 非必要场景不得使用 `priority(999)` 或同类技巧规避约束冲突。
- 新增字段、参数或状态若依赖上游透传，必须沿完整调用链补齐数据来源、映射、构造和传递路径；不得只在消费端声明变量、追加参数或做局部占位使当前文件先通过编译。
- 严格执行网络边界、缓存、重试、鉴权、错误分层和幂等语义。
- 严格补齐日志、埋点、性能观测和排障取证链路。
- 任何新增或修改规则，必须说明它是在新增能力、修正表达、合并重复，还是退役旧规则；若不能说明替代关系，默认不新增。

## 交付门禁
- 涉及并发修复时，明确隔离策略、取消策略、过期结果处理和验证方法。
- 涉及迁移时，明确阶段计划、兼容层、灰度范围、失败信号和回滚路径。
- 涉及发布或 CI 风险时，明确构建配置、依赖来源、门禁条件和发布观测项。
- 涉及性能优化时，明确基线指标、优化动作和优化后对比。
- 任何改动都必须声明“已覆盖、未覆盖、残留风险”。

## 参考资料加载规则
- 默认只读取当前任务直接相关的 2 到 4 份参考资料；不要先通读全部文档。
- 若任务命中高风险门禁文档，例如测试策略、迁移风险、构建发布、MCP 控制或团队协作规则，允许超出 4 份，但必须先区分主文档和附加门禁文档。
- 当任务跨越多个维度时，优先顺序是：根因/边界 -> 状态/并发 -> 测试验证 -> 迁移或发布风险。

## 快速检查
- [ ] 是否已经定义清楚边界、依赖方向和状态归属？
- [ ] 是否已经定位根因，而不是只修表象？
- [ ] 是否已经说明任务创建、持有、取消和释放关系？
- [ ] 是否已经避免 DTO、底层错误或共享可变状态向上泄露？
- [ ] 是否已经补齐测试策略、观测信号和残留风险？
- [ ] 如果是迁移或发布相关改动，是否已经定义灰度和回滚？

---
> Source: [i-stack/ai-coding-kit](https://github.com/i-stack/ai-coding-kit) — distributed by [TomeVault](https://tomevault.io).
<!-- tomevault:4.0:skill_md:2026-06-16 -->