菜单
通过用户访谈创建包含微小提交的详细重构计划, 然后将其归档为 GitHub issue. 当用户想要规划重构, 创建重构 RFC, 将重构分解为安全的增量步骤, 提到 "重构计划" 或 "拆解重构" 时使用.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 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 | request-refactor-plan |
| description | 通过用户访谈创建包含微小提交的详细重构计划, 然后将其归档为 GitHub issue. 当用户想要规划重构, 创建重构 RFC, 将重构分解为安全的增量步骤, 提到 "重构计划" 或 "拆解重构" 时使用. |
当用户想要创建重构请求时, 将调用此技能. 你应该执行以下步骤. 如果你认为没有必要, 可以跳过步骤.
询问用户对他们想要解决的问题的详细描述以及任何潜在的解决方案想法.
探索仓库以验证他们的断言并了解代码库的当前状态.
询问他们是否考虑过其他选项, 并向他们展示其他选项.
对用户进行实现方面的访谈. 要极其详细和彻底.
敲定实现的确切范围. 明确你计划更改什么和不计划更改什么.
在代码库中查找此区域的测试覆盖率. 如果测试覆盖率不足, 询问用户他们的测试计划是什么.
将实现分解为微小提交的计划. 记住 Martin Fowler 的建议: "使每个重构步骤尽可能小, 这样你就可以始终看到程序正常工作."
使用以下模板为 issue 描述创建 GitHub issue:
从开发人员的角度描述开发人员面临的问题.
从开发人员的角度描述问题的解决方案.
一个详细的实现计划. 用简单的英语编写计划, 将实现分解为尽可能小的提交. 每个提交都应该使代码库保持在工作状态.
已做出的实现决策列表. 这可以包括:
不要包含特定文件路径或代码片段. 它们可能很快就会过时.
已做出的测试决策列表. 包括:
对此重构范围外事项的描述.
关于该重构的任何进一步说明.
