这个 Skill 能做什么，适合哪些场景？
这是 manaflow-ai/cmux 仓库内 25 个技能之一的 cmux-architecture。它是一份面向 AI 编码代理的知识型规范文档，没有任何可执行脚本，纯粹通过 SKILL.md 约束代理在 cmux 代码库中写 Swift 的方式。内容覆盖五层包架构与依赖方向、依赖倒置与构造器注入、单类型单文件组织、Swift-DocC 文档要求、包设计纪律、可测试性约束，以及一份带豁免条款的 Swift 6 并发禁用清单。适用范围严格限定于 cmux 这个仓库本身。
- 强制五层包分层（Core → Services → Domain → UI → Executable），依赖只向下指，包图必须无环。
- 规定依赖倒置写法：底层发布协议、高层只依赖 any Protocol、仅构造器注入、无单例。
- 约束文件组织：一个主要类型一个文件、扩展命名规则、类型擦除包装器的位置。
- 要求每个 public 符号写 Swift-DocC 注释，行为改动与文档同一次提交完成。
- 列出 Swift 6 并发禁用项（锁、Combine、completion handler、DispatchQueue.main.async 等）及带理由的豁免情形。
- 要求包内 public 类型可脱离 App 和 AppKit 被测试，依赖经 init 注入。
- 向 cmux 仓库贡献新 Swift Package 的开发者，需要知道包边界、pbxproj 双 target 接线和 workspace 目录规则。
- 用 Claude Code 或 Codex 在 cmux 里新增 Coordinator/Service/Repository 的代理任务，需要先加载分类和分层约束。
- 重写或拆分 cmux 中 ContentView.swift、Workspace.swift 等巨型文件时，需要遵守扩展下移与子模型分解规则。
- 审查 cmux 的 PR：可依据禁用清单（锁、Combine、静态测试钩子）快速判断改动是否违规。
- 为 cmux 新包编写测试或文档时，需要 DocC 注释格式和 test-instantiation 模式。
- 任何不涉及 cmux 仓库的 Swift 或其他语言项目——其中的包分层、命名与并发规则都是 cmux 专属约定，其他代码库照搬并无依据。
- 想要 cmux 终端本身使用说明的用户——本技能只讲代码架构，不涉及 CLI、SSH、浏览器或通知功能。
- 初学 Swift 或并发的读者——文档假定你已熟悉 actor、@Observable、SwiftPM，且只给规则不教学。
如何安装这个 Skill？
- 该技能仅适用于 cmux 仓库的 Swift/SwiftPM 贡献流程，勿泛化到其他项目使用。
- 许可元数据为 NOASSERTION，实际为 GPL-3.0-or-later（web/ 等服务器目录为 BUSL-1.1）；合规使用前请核对仓库 LICENSE。
- 静态审阅未执行任何脚本或构建；pbxproj/workspace 校验脚本的实际行为未经独立验证。
- 技能内容为英文，无中文文档；对中文用户无本地化支持。
- 发布方未经 FollowSkills 注册表核验，身份视为未知。
- 本地文件系统
cmux repository checkout (Swift/Xcode project)
本技能已包含在 manaflow-ai/cmux 仓库的 skills/ 目录中，源文档未给出单独的安装命令；获取整套技能集合的常规方式是克隆仓库。
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/manaflow-ai/cmux.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/cmux-architecture" ~/.claude/skills/
rm -rf "$tmp"根据源仓库地址和 Skill 路径自动生成，只复制这个 Skill 的文件夹。如果上文有作者提供的安装方式，请优先按作者说明操作；想只在当前项目中使用，把 ~/.claude/skills 换成项目里的 .claude/skills。
如何使用这个 Skill？
安装后，把下面任意一句发给 Agent 即可触发：
- 我要在 cmux 里新建一个管理浏览器域的 Swift Package，先按 cmux-architecture 技能告诉我包该放哪、依赖怎么接。
- 帮我把 cmux 的 Workspace.swift 拆成多个类型文件，遵守 cmux-architecture 的一类型一文件和 Coordinator/Service/Repository 分类。
- 审查这个 PR 里的并发改动是否符合 cmux-architecture 的 Swift 6 规则，逐条指出锁和 DispatchQueue 的违规用法。
- 为我在 cmux 新写的 CmuxTerminal 包补上符合规范的 DocC 注释和可注入依赖的测试实例化模式。
SKILL.md 的 description 声明了触发条件：在向 cmux 添加或大幅重写 Swift 文件、Swift 包、coordinator、service、repository 或公共包 API 之前使用。代理加载后应按其规则执行：先判断改动属于哪一层与哪类实体（Coordinator/Service/Repository），按五层依赖方向放置代码，遵守一类型一文件与 DocC 注释要求，避免禁用并发原语，必要时查四份 references 文档（package-boundaries、concurrency-carveouts、file-api-discipline、swift-6-0-compatibility）获取细节。
这个 Skill 有哪些优点和局限？
- 规则极其具体且可执行：从 pbxproj 双 target 接线到检查脚本命令（check-workspace-package-groups.py）都有明确指引。
- 禁用清单每项都给出理由和合法豁免情形，代理和审阅者都能判断边界。
- 自带四份 references 文档承载细节，主文档保持可读。
- 完全绑定于 cmux 这一个仓库，对其他项目没有可迁移价值。
- 纯文档型技能，无脚本、无自动校验，规则是否被遵守依赖代理自觉与 CI 中的检查脚本。
- 仓库 License 字段为 NOASSERTION，技能文件本身的再分发许可需自行向 LICENSE 核实（README 称项目主代码为 GPL-3.0-or-later）。
这个 Skill 与同类方案有什么区别？
与相关 Skills 并排比较；分数均按同一 FSRS 标准得出。
| Skill | FS 评分 | Star 数 | 最近更新 | License |
|---|---|---|---|---|
| cmux 架构规范技能 本页 | 63 · 推荐 | ★ 28k | 1 天前 | NOASSERTION |
| Swift 并发专家技能（Swift Concurrency Pro） | 65 · 推荐 | ★ 561 | 4 个月前 | MIT |
| Swift 并发审查专家技能 | 60 · 推荐 | ★ 561 | 4 个月前 | MIT |
| DeepChat 规格驱动开发（SDD）技能 | 58 · 推荐 | ★ 6.4k | 3 天前 | Apache-2.0 |
| SwiftUI Pro | 57 · 谨慎使用 | ★ 5.2k | 4 天前 | MIT |
同类做法是通用的 Swift 风格指南（如 Apple 的 API Design Guidelines 或 Swift Concurrency 迁移指南），但那些是通用建议；本技能是 cmux 代码库的强制工程约定，包含仓库专属的包结构、workspace 校验脚本和豁免政策，二者定位不同。
FollowSkills 如何评估这个 Skill？
该技能是纯架构规范文档，不请求权限、不执行脚本、无外部副作用与数据流，敏感数据风险极低；仓库含真实 SECURITY.md 与 GPL-3.0 许可及源码归属。扣分点：许可元数据为 NOASSERTION（仓库实际为 GPL-3.0，但 skill 自身未标注），发布方未经注册表核验，且涉及 PostHog 远程特性开关的指引未说明遥测数据流细节。
指令内部自洽，层次、规则与四个 references 文件相互引用且无矛盾，pbxproj/workspace 检查有配套脚本路径。扣分点：静态审阅未执行任何关键路径，无法验证脚本（check-workspace-package-groups.py 等）确实存在并按描述工作；对异常输入（如规则冲突、旧包例外）仅部分处理，故不超过静态上限。
触发条件在 description 中写得相当精确（新增或重写 Swift 文件/包/Coordinator/Service/公共 API 前使用），非适用范围也有明确声明（不追溯旧代码、不作为既有包的设计参考），中文简繁 README 表明环境适配意识。扣分点：仅适用于 cmux 仓库贡献场景，技能未声明这一强边界；无中文技能内容本身，触发面窄。
信息架构分层良好：主文件概览 + 四个详细 references，渐进披露清晰；引用文件均随附于 skill 目录。扣分点：skill 自身无版本号、changelog 或更新路径说明；许可归属依赖仓库级 LICENSE 而非 skill 内声明；名称与描述与实际能力相符。
对 cmux 贡献者而言，该规范直接可用且边际价值高——将口头约定固化为可检查的规则（含 CI 校验脚本钩子），远优于人工推断架构约定。扣分点：静态审阅无法验证产出代码是否被 CI 实际接受，无代表性输出样例，比较收益证据限于文件内部声称。
规则可追溯至具体文件路径、脚本名和 CI 工作流（仓库含真实 GitHub Actions 测试工作流），引用文件提供可核查细节。扣分点：静态审阅无法独立复现任何结论；规则与代码实际状态（如 Packages/ 目录结构）的交叉验证未执行，证据类型单一。
点击维度查看打分理由
证据充分度：低 — 主要依赖静态检查、作者材料或有限演示；适合发现线索，不适合做高风险决策。
查看完整评分方法 →