swift-architecture-skill

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Swift Architecture Skill

Swift架构Skill

Overview

概述

Use this skill to pick the best Swift architecture playbook for SwiftUI/UIKit codebases and apply it to the user’s task.

使用本Skill可为SwiftUI/UIKit代码库选择最合适的Swift架构操作手册，并将其应用到你的任务中。

Workflow

工作流程

Step 1: Analyze the Request Context

步骤1：分析请求上下文

Before selecting an architecture, capture:

task type (new feature, refactor, PR review, debugging)
UI stack (SwiftUI, UIKit, or mixed)
scope (single screen, multi-screen, app-wide)
existing conventions to preserve

在选择架构之前，需明确以下信息：

任务类型（新功能开发、重构、PR审查、调试）
UI框架（SwiftUI、UIKit或混合）
范围（单页面、多页面、全应用）
需要遵循的现有规范

Step 2: Select the Architecture

步骤2：选择架构

If the user explicitly names an architecture, treat it as the initial candidate and run a fit check before committing:

validate against UI stack fit (SwiftUI/UIKit/mixed), state complexity, effect orchestration needs, team familiarity, and existing codebase conventions
if it fits, proceed with the requested architecture
if it mismatches key constraints, explicitly explain the mismatch and recommend the closest-fit alternative from
```
references/selection-guide.md
```
if the user still insists on a mismatched architecture, proceed with a risk-mitigated plan and state the risks up front

When no architecture is named, load

references/selection-guide.md

and infer the best fit from stated constraints (state complexity, team familiarity, testing goals, effect orchestration needs, and framework preferences). Explain the recommendation briefly.

Architecture reference mapping:

MVVM →
```
references/mvvm.md
```
MVI →
```
references/mvi.md
```
TCA →
```
references/tca.md
```
Clean Architecture →
```
references/clean-architecture.md
```
VIPER →
```
references/viper.md
```
Reactive →
```
references/reactive.md
```
MVP →
```
references/mvp.md
```
Coordinator →
```
references/coordinator.md
```

如果用户明确指定了某一架构，将其作为初始候选方案，在确定使用前先进行适配性检查：

根据UI框架适配性（SwiftUI/UIKit/混合）、状态复杂度、事件编排需求、团队熟悉度和现有代码库规范进行验证
若适配，则采用该指定架构
若与关键约束不匹配，需明确说明不匹配的原因，并从
```
references/selection-guide.md
```
中推荐最适配的替代方案
若用户仍坚持使用不匹配的架构，则采用风险可控的方案，并提前说明相关风险

当用户未指定架构时，加载

references/selection-guide.md

，根据给定的约束条件（状态复杂度、团队熟悉度、测试目标、事件编排需求和框架偏好）推断最适配的架构，并简要说明推荐理由。

架构参考映射：

MVVM →
```
references/mvvm.md
```
MVI →
```
references/mvi.md
```
TCA →
```
references/tca.md
```
Clean Architecture →
```
references/clean-architecture.md
```
VIPER →
```
references/viper.md
```
Reactive →
```
references/reactive.md
```
MVP →
```
references/mvp.md
```
Coordinator →
```
references/coordinator.md
```

Step 3: Analyze Existing Codebase (When Applicable)

步骤3：分析现有代码库（如适用）

When code already exists:

detect current architecture and DI style
note concurrency model (async/await, Combine, GCD, mixed)
align recommendations to local conventions

当已有代码存在时：

检测当前架构和依赖注入（DI）风格
记录并发模型（async/await、Combine、GCD或混合）
使建议与本地规范保持一致

Step 4: Produce Concrete Deliverables

步骤4：生成具体交付物

Read the selected architecture reference and convert its guidance into deliverables tailored to the user's request:

File and module structure: directory layout with file names specific to the feature
State and dependency boundaries: concrete types, protocols, and injection points
Async strategy: cancellation, actor isolation, and error paths
Testing strategy: what to test, how to stub dependencies, and example test structure
Migration path (for refactors): incremental steps to move from current to target architecture
UI stack adaptation: where SwiftUI and UIKit guidance should differ for the chosen architecture

读取选定的架构参考文档，将其指导内容转换为符合用户需求的交付物：

文件与模块结构：针对该功能的目录布局及具体文件名
状态与依赖边界：具体类型、协议和注入点
异步策略：取消机制、actor隔离和错误处理路径
测试策略：测试内容、依赖桩实现方式和测试结构示例
迁移路径（针对重构任务）：从当前架构过渡到目标架构的增量步骤
UI框架适配：针对所选架构，SwiftUI与UIKit的指导差异

Step 5: Validate with Checklist

步骤5：使用清单验证

End with the architecture-specific PR review checklist from the reference file, adapted to the user's feature.

最后附上参考文档中特定架构的PR审查清单，并根据用户的功能需求进行调整。

Output Requirements

输出要求

Keep recommendations scoped to the requested feature or review task.
Prefer protocol-based dependency injection and explicit state modeling.
Flag anti-patterns found in existing code and provide direct fixes.
Include cancellation and error handling in all async flows.
For explicit architecture requests, include a short fit result (
```
fit
```
or
```
mismatch
```
) with 1-2 reasons.
For mismatch cases, include one closest-fit alternative and why it better matches the stated constraints.
When writing code, include only the patterns relevant to the task — do not dump entire playbooks.
Treat reference snippets as illustrative by default; add full compile scaffolding only if the user asks for runnable code.
Ask only minimum blocking questions; otherwise proceed with explicit assumptions stated up front.
When reviewing PRs, use the architecture-specific checklist and call out specific violations with line-level fixes.

建议需紧扣用户请求的功能或审查任务范围
优先采用基于协议的依赖注入和显式状态建模
标记现有代码中的反模式，并提供直接修复方案
在所有异步流程中包含取消和错误处理
对于明确指定架构的请求，需包含简短的适配结果（
```
fit
```
或
```
mismatch
```
）及1-2个理由
对于不匹配的情况，需提供一个最适配的替代方案，并说明其更符合给定约束的原因
编写代码时，仅包含与任务相关的模式——不要输出完整的操作手册
默认将参考片段作为示例；仅当用户要求可运行代码时，才添加完整的编译脚手架
仅提出必要的阻塞性问题；否则基于明确的假设继续推进
审查PR时，使用特定架构的清单，指出具体的违规内容并提供行级修复方案