Menu
使用并行子代理为模块生成多个截然不同的接口设计. 当用户想要设计 API, 探索接口选项, 比较模块形状, 提到 "设计两版", "接口设计" 或 "design it twice" 时使用.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Convert EPUB books into clean, narration-friendly plain text for local VibeVoice audiobook generation, with optional chunking for stable long-form TTS. Use when the user has an .epub and wants text cleanup, chunk prep, or a local audiobook workflow for VibeVoice.
Convert technical book chapters, papers, tutorials, or lecture notes into precise but listenable audiobook narration scripts, especially when the source contains LaTeX formulas and code in Lisp, C, Java, C#, or similar languages. Use this skill for math/code narration, SSML scripts, audiobook production plans, synchronized transcripts, and compact-vs-precise reading policies.
Help build, debug, refactor, test, and review ClojureDart applications that target Flutter, native mobile/desktop, web, or plain Dart. Use when the user asks about ClojureDart, .cljd files, cljd.build, deps.edn :cljd/opts, cljd.flutter, Dart package interop from Clojure syntax, Flutter widget construction in ClojureDart, hot reload, REPL, or ClojureDart testing.
使用捆绑的 Babashka 脚本修复 Emacs Lisp、Scheme、Common Lisp 等 Lisp 文件的括号/分隔符错误。 当用户提到 Lisp 括号错配、Paren Edit Death Loop、`.el/.lisp/.scm` 文件修复，或想在 Claude Code、Codex、Gemini 中批量修复非 Clojure Lisp 文件时使用。
从当前对话中提取 DDD 风格的通用语言术语表, 标记歧义并提出规范术语. 保存到 UBIQUITOUS_LANGUAGE.md. 当用户想要定义领域术语, 构建术语表, 强化术语, 创建通用语言, 提到 "通用语言", "术语表", "domain model" 或 "DDD" 时使用.
在 Clojure 项目中组合使用 `clj-nrepl-eval`、`clj-paren-repair-claude-hook` 和 `clj-paren-repair` 来完成 nREPL 求值与分隔符修复. 当用户提到 Clojure、nREPL、括号/分隔符错误、Paren Edit Death Loop、Claude hooks，或想在 Claude Code、Codex、Gemini 中验证和修复 `.clj/.cljs/.cljc/.bb` 文件时使用.
| name | design-an-interface |
| description | 使用并行子代理为模块生成多个截然不同的接口设计. 当用户想要设计 API, 探索接口选项, 比较模块形状, 提到 "设计两版", "接口设计" 或 "design it twice" 时使用. |
基于《软件设计的哲学》中的 "Design It Twice": 你的第一个想法不太可能是最好的. 生成多个截然不同的设计, 然后进行比较.
在设计之前, 了解:
询问: "这个模块需要做什么? 谁会使用它?"
使用 Task 工具同时生成 3+ 个子代理. 每个必须产生一个截然不同的方法.
每个子代理的提示模板:
为以下内容设计一个接口: [模块描述]
需求: [收集的需求]
此设计的约束: [为每个代理分配不同的约束]
- Agent 1: "最小化方法数量 -- 目标最多 1-3 个方法"
- Agent 2: "最大化灵活性 -- 支持多种用例"
- Agent 3: "为最常见的场景优化"
- Agent 4: "从 [特定范式/库] 中获取灵感"
输出格式:
1. 接口签名(类型/方法)
2. 使用示例(调用者如何使用)
3. 该设计在内部隐藏了什么
4. 这种方法的权衡
展示每个设计, 包括:
1.** 接口签名** - 类型, 方法, 参数 2.** 使用示例** - 调用者在实践中如何使用它 3.** 隐藏的内容** - 保持内部的复杂性
按顺序呈现设计, 以便用户可以在比较之前吸收每种方法.
显示所有设计后, 对它们进行比较:
以散文方式讨论权衡, 而非表格. 突出显示设计差异最大的地方.
通常最好的设计结合了多个选项的见解. 询问:
来自《软件设计的哲学》:
接口简洁性: 更少的方法, 更简单的参数 = 更容易学习和正确使用.
通用性: 可以在不更改的情况下处理未来的用例. 但要注意过度通用化.
实现效率: 接口形状是否允许高效实现? 还是强制笨拙的内部实现?
深度: 隐藏大量复杂性的小接口 = 深度模块(好). 实现薄弱的大接口 = 浅层模块(避免).