greysonOuyang/ios-engineering-skill

iOS 工程

目的

使用此单一技能完成现有 iOS 产品的完整生命周期：

产品决策
→ 设计冻结
→ 实现
→ 审查
→ 调试
→ UI 验证
→ 功能测试
→ 全应用审计
→ 最终验收

该技能是通用的。产品事实、领域规则、真实模块名称、构建方案、测试目标、设计令牌和组件名称必须来自活动仓库。

调用

推荐命令：

/ios plan <需求>
/ios implement <需求或任务>
/ios review <范围>
/ios debug <观察到的失败>
/ios ui <replicate | review | fix> <屏幕或设计>
/ios test feature <功能>
/ios audit app
/ios verify <需求或变更>

自然语言等效形式也是有效的。如果用户明确指定了模式，请使用该模式。

模式路由

选择一个主要模式：

• plan：决定产品结构、需求范围、用户体验、交互、UI 结构、数据循环、执行分组和验收标准。
• implement：在冻结的需求下更改生产行为。
• review：检查已完成或部分工作是否存在缺陷和遗漏。
• debug：将观察到的失败追溯到其根本原因并添加回归保护。
• ui：复制、审查或修复渲染后的 iOS UI。
• test：为一个功能或契约添加聚焦的 XCTest 覆盖。
• audit：运行分阶段的全应用质量保证和跨流程回归。
• verify：决定一个需求是否真正完成。

不要同时激活多个完整工作流。当任务跨越边界时，主要模式可以从其他模式加载引用。

必需的项目发现

在应用通用规则之前，按以下顺序搜索项目特定来源：

1. .agent/project-profile.md
2. docs/project/ios-engineering-profile.md
3. docs/ENGINEERING-SKILL-PROFILE.md
4. 当前问题、需求文档、需求或设计工件
5. 产品和领域规则
6. 架构和数据流文档
7. 用于 UI 工作的设计系统和组件文档
8. 测试概况、方案、目标和验证命令

项目事实优先于此技能中的示例。项目规则不能削弱数据完整性、确定性测试、安全性、可访问性或证据要求。

通用操作规则

1. 在接受请求的控制或表面作为解决方案之前，先理解用户的真实目标。
2. 在提议新模块、数据所有者或组件之前，先检查现有产品和实现。
3. 优先考虑 重用 → 扩展 → 重构 → 重建，按此顺序。
4. 默认推荐一种解决方案。仅在有实质性权衡或未解决的产品冲突时提供替代方案。
5. 将持久的产品事实与实现说明和一次性审计证据分开。
6. 在修改有状态行为之前，确定权威状态所有者及完整的读/写路径。
7. 保留明确的非目标和已正确行为。
8. 修复最早的错误假设或转换，而不仅仅是可见的症状。
9. 使用仓库的真实构建、测试、运行时和可视化入口点进行验证。
10. 分别报告已确认的事实、推断的风险、未知项、证据和剩余阻塞项。

硬性规则

• 不要捏造产品行为、模块名称、令牌名称、测试方案或目标名称。
• 不要创建并行的数据源来使功能看起来有效。
• 不要通过静默回退来隐藏缺失的业务数据。
• 不要根据当前可变配置重写历史事实。
• 不要在没有可达的失败路径时将代码异味归类为确认的错误。
• 不要为了使测试通过而削弱断言、验证或业务规则。
• 不要使用任意的 sleep 作为同步或正确性的证明。
• 不要仅仅为了匹配静态截图而更改产品语义。
• 在相关范围被扫描并将发现分组之前，不要开始修复审查表面。
• 当用户已经请求实现或修复时，不需要用户确认确定性范围内的修复。
• 不要自动解决真正的产品/设计冲突；记录冲突并推荐决策。
• 不要从编译成功、已勾选框、注释或仅模拟测试中声明完成。
• 不要将每个观察结果都转化为当前范围的工作；将当前、延后、历史和全局系统问题分类。

引用加载

只加载任务所需的内容：

• 产品架构、需求、用户体验、信息架构或执行提示：
  • modes/plan.md
  • references/product-architecture.md
  • references/requirement-and-ux.md
  • references/interaction-and-state-design.md
• 任何生产变更：
  • modes/implement.md
  • references/core-engineering-rules.md
• 写入、删除、持久化、历史记录、通知、缓存、小组件、手表或跨页面同步：
  • references/data-consistency.md
  • references/fallback-and-error-handling.md
• 代码审查或无法解释的行为：
  • references/bug-patterns.md
• SwiftUI、导航、sheet、安全区域、键盘、可访问性或布局：
  • references/swiftui-and-ios-ui.md
• 设计再现或渲染视觉效果审查：
  • references/ui-replication.md
  • references/visual-quality-review.md
• 功能测试：
  • modes/test.md
  • references/testing.md
• 全应用质量保证：
  • modes/audit.md
  • references/full-app-audit.md
• 验收或完成声明：
  • modes/verify.md
  • references/evidence-and-reporting.md
• 本地化或对文案敏感的工作：
  • references/localization.md

输出策略

默认输出简洁、可执行的内容。仅当用户要求完整规范或审计报告时才详细展开。

每个正式输出必须明确展示以下内容：

• 检查过的范围
• 产品或工程决策
• 已确认的发现或完成的更改
• 保留的行为和明确的非目标
• 证据
• 未解决的风险、决策或未验证的条件
• 下一步需要的操作（如果有）

当需要持久的报告或执行提示时，请使用 templates/ 下对应的文件。