القائمة
使用并行 sub-agents 为一个 module 生成多套差异显著的 interface 设计。适用于用户希望设计 API、探索 interface 选项、比较 module 形态，或提到“design it twice”的场景。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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（应避免）。