Menu
使用并行 sub-agents 为一个 module 生成多套差异显著的 interface 设计。适用于用户希望设计 API、探索 interface 选项、比较 module 形态，或提到“design it twice”的场景。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
运行交互式 QA session：用户通过对话报告 bugs 或 issues，agent 随后创建 GitHub issues；同时在后台探索 codebase，获取上下文和 domain language。适用于用户希望报告 bugs、开展 QA、通过对话创建 issues，或提到“QA session”的场景。
通过用户访谈创建一份由微小 commits 组成的详细 refactor plan，并将其提交为 GitHub issue。适用于用户希望规划 refactor、创建 refactoring RFC，或将 refactor 拆分为安全的增量步骤。
从当前对话中提取一份 DDD 风格的 ubiquitous language glossary，标出歧义并提出规范术语，保存到 UBIQUITOUS_LANGUAGE.md。适用于用户希望定义 domain terms、建立 glossary、收紧术语、创建 ubiquitous language，或提到“domain model”或“DDD”的场景。
询问当前情境适合使用哪个 Skill 或工作流。本 Skill 是仓库内其他 Skills 的路由入口。
从用户指定的固定点（commit、branch、tag 或 merge-base）开始，从两个维度审查代码变更：Standards 检查代码是否遵守仓库记录的编码规范，Spec 检查实现是否符合原始 Issue、PRD 或规格。两个审查由并行子 Agent 分别完成，再并列汇报。适用于用户希望审查分支、PR、开发中的改动，或要求“审查自 X 以来的变更”时。
用于设计深模块的共享词汇体系。适用于用户希望设计或改进模块接口、寻找深化机会、决定 seam 的位置、提高代码的可测试性或 Agent 可导航性，或其他 Skill 需要使用深模块词汇时。
| name | design-an-interface |
| description | 使用并行 sub-agents 为一个 module 生成多套差异显著的 interface 设计。适用于用户希望设计 API、探索 interface 选项、比较 module 形态，或提到“design it twice”的场景。 |
本 skill 基于《A Philosophy of Software Design》中的 “Design It Twice”：你的第一个想法很可能不是最佳方案。先生成多套差异显著的设计，再进行比较。
开始设计前，先弄清楚：
询问：“这个 module 需要完成什么？谁会使用它？”
使用 Task tool 同时启动 3 个以上的 sub-agents。每个 sub-agent 必须提出一套差异显著的方案。
每个 sub-agent 使用以下 Prompt 模板：
为以下 module 设计 interface：[module description]
要求：[gathered requirements]
当前设计的约束：[为每个 Agent 分配不同约束]
- Agent 1：“尽量减少 method 数量，最多 1–3 个”
- Agent 2：“尽量提高灵活性，支持多种使用场景”
- Agent 3：“围绕最常见的调用场景进行优化”
- Agent 4：“参考 [specific paradigm/library] 的设计思路”
输出格式：
1. Interface signature（types/methods）
2. Usage example（caller 如何使用）
3. 该设计在内部隐藏什么
4. 该方案的取舍
每套设计都应展示：
依次展示各套设计，让用户先理解每个方案，再进入比较。
展示完全部设计后，从以下方面进行比较：
使用 prose 讨论取舍，不要使用 tables。重点说明不同设计分歧最大的地方。
最佳设计经常会结合多套方案中的优点。询问：
以下标准来自《A Philosophy of Software Design》：
Interface simplicity：Methods 越少、params 越简单，就越容易学习和正确使用。
General-purpose：无需修改即可处理未来的使用场景，但要警惕过度泛化。
Implementation efficiency：Interface 的形态是否允许高效实现，还是会迫使内部采用别扭结构？
Depth：小 interface 隐藏大量复杂度，构成 deep module（理想）。大 interface 配合单薄 implementation，构成 shallow module（应避免）。