关于 unsloppify
用于审阅和改写文稿的写作规范技能,适用于文档、PR 文本、报告、营销文案和大量代码注释等交付内容。它通过识别套话、夸大表达和模板化结构,推动文字清晰、具体地传达信息。
主要功能
- 01按交付内容类型选择写作规则
- 02检查六类常见写作问题
- 03扫描短语及结构性表达
- 04提供文稿审阅与改写流程
- 05保留事实、限定语和引用
适用场景
- 01审阅报告并改写含糊表达
- 02精简 PR、提交说明或发布说明
- 03检查营销文案和代码注释
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ woerndl/ unsloppify --skill unsloppify安装后在 Claude Code 中输入/unsloppify确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
LICENSECHANGELOG.mdREADME.mdbaseline/CLAUDE-baseline.mdreferences/phrases.txtpatterns.mdscripts/scan.shtests/README.mdtests/cases/01-blog-drama.md02-blog-gravitas.md04-clean-docs.md03-docs-teacher.md08-code-comment-necessity.md06-pr-false-precision.md05-pr-process-leak.md07-commit-slang.md09-code-comment-leak.md13-quoted-slop.md10-report-false-precision.md11-academic-hedges.md12-marketing-tapestry.md14-personal-essay.md15-smoke-test-dose.md17-comment-negation-tails.md16-docs-dramatic-absolutes.md18-docs-hyphen-compounds.md详细介绍
unsloppify
Slop 是指那种为了表现而写、而非为了传达信息的文字。修正方式绝不是装饰。 直接说出平实的版本。这条原则适用于任何草稿,无论作者是谁, 无论是人还是模型写的。评判文字应基于文字本身,而不是谁写的。
何时加载
当某个文本产物就是交付物,或是交付物的主要部分时加载此技能:文档、PR 或提交文本、发布说明、报告、营销文案、 大量代码注释。围绕其他工作产生的文字不算:聊天回复、状态更新、工具评论、完成摘要。 那些遵循写作基线。如果此技能已加载,但任务不符合条件,跳过该流程并继续任务。
流程
在机械性的内部规则之外(长破折号、分号和 UTF 中点,见到即删),下面每一个标记都是 一个提示,用来检查被标记的形式是否确实必要,是否是精确情境下没有平实短语可替代的那个确切词。该形式仍然可用,但只有具备这一理由时才用。 目标是改写被识破的套路,而不是写出一份胆怯到什么都不敢说的草稿。
起草:
- 指明语境(散文、文档、PR 或提交文本、代码注释、学术)。写作时应用其下方规则。最多再加载一个次要语境。
- 在产出最终文本之前,立即重读六种失败模式。 规则在长时间会话的早期读过就会淡忘。这一步正是为此存在。
- 依据六项测试自检。单个实例可以保留。重复或聚集才是失败。
- 通查草稿中词与词之间的连字符。每个复合修饰语要么是受众共享的既有术语, 要么是字面的代码标识符,要么用平实词语展开说明。这一迹象足够常见,值得单独过一遍。
审计现有文档:
- 对文档运行 scripts/scan.sh(或 rg -i -f references/phrases.txt)。 这会以零推理成本找出字面上的迹象。扫描器只捕捉短语层面的迹象。结构性迹象(横幅注释、价值回响、 加粗优先格式)需要你自己阅读。列表最后是分诊分组 (裸 can not、never、gate、actually、land、ship、sits、arrow、否定尾巴、连字符复合词),其中许多命中是合法用法。那些命中是 需要逐个实例回答的问题,不是要报告的发现。
- 通读文档结构一次:标题、开头、结尾。标记 重复的形态、重复的隐喻、模板化节拍。
- 分段阅读文本。对每一段应用六项测试。长文档 需要不止一遍。
- 在改写任何内容之前,把所有候选项收集到发现列表中(位置、引文、模式)。
- 依据列表改写。然后通读整个结果一次,检查语气、事实和连贯性。对于深度审计,加载 references/patterns.md。
防护
规则冲突时的优先级:事实含义优先于被引用材料优先于 用户要求的语气优先于领域语域优先于任何反 slop 规则。
- 事实在每次改写中都保留:数字、名称、日期、URL、引文、单位、 代码标识符、范围词、否定。
- 保留承载内容的模糊限定(法律、医疗、安全、学术)。
- 不要过度纠正成反 slop 语域。断奏式有力结尾、“Not X. Y.”式片段,以及强行直白也是迹象。
- 正在被讨论的引用 slop 保持为引用。
六种失败模式
1. 重要性膨胀
诱因:模型会堆砌辞藻以显得权威,于是被断言的分量取代了被展示的分量。 测试:删掉那个评价性词语。如果意思仍然成立,这个词就是装饰。 禁用:crucial、essential、vital、paramount、transformative、cannot be overstated、more important than ever、plays a key role、stands as a testament、paving the way,以及戏剧化的绝对词(cannot、never、always),而平实的 "not" 就能陈述事实。豁免:在同一句中点名的依赖关系,字面意义上的不可能。 示例:"The cache plays a crucial role in overall system performance." -> "The cache cuts read latency by 40%." 推断:任何评价事物而非描述事物的词。
2. 人为制造的戏剧性
诱因:模型会借用说服性文案的节奏,于是在并不存在张力的地方也搭起戏台。 测试:这句话是在制造内容并不兑现的悬念,还是通过否定其反面来陈述事实? 禁用:"it isn't just X, it's Y"、"No X. No Y. Just Z."、"The catch?"、自问自答、单行一锤定音的碎片句、"the truth is"、"let that sink in",以及否定性尾缀(", not X.", ", no X either."),而肯定陈述本身已承载事实。豁免:为预防肯定陈述可能留下的误读而作的对比("per host, not per request")。 示例:"This isn't caching. It's a whole new architecture." -> "The change adds a cache." 推断:任何承诺了事实并不支撑的揭示的措辞。
3. 表演性语域
诱因:模型会搬来显得有威望的词汇和圈内黑话来标榜专业性。 测试:一个平实的动词能否表达同样的意思?那就用它。 禁用:delve、tapestry、seamless、leverage、robust、utilize、facilitate、serves as、functions as、footgun、blast radius、battle-tested,以及临时拼造的连字符复合词("review-shaped output"、"genuine-need escape hatch"),而平实的词本可直接把意思讲清。豁免:按字面精确含义使用的术语,或受众共享的既有复合词(thread-local、copy-on-write)。一段中出现多个复合词,即使每个单独都合格,也算失败。 示例:"The validator serves as a gatekeeper for malformed input." -> "The validator rejects malformed input." 推断:任何因听起来好听而非因表达所需而选用的词。
4. 虚假的精确
诱因:模型会用听起来笃定的标签和笼统的归因来填补空缺,而非给出具体机制。 测试:说出机制、来源或数字。如果说不出,就删掉这个论断。 禁用:没有点名机制的诊断性标签(race condition、deadlock、memory leak)、"studies show"、"everything from X to Y"、凭空发明的概念标签。 示例:"The crash is probably a race condition." -> "The reader thread can see the buffer after the length update but before the payload write." 推断:任何听起来具体却没有点名任何可核查之物的论断。
5. 套模板
诱因:模型会补全一种熟悉的文章形状,于是开头和结尾凭反射而来。 测试:这句话承载内容,还是只填补了形式所预期的位置? 禁用:"In conclusion"、"In today's fast-paced world"、收尾式标题、反射性的三段式、粗体开头的项目符号标签。 示例:"Performance: The new index makes lookups faster." -> "Lookups now hit the new index and return in under 5 ms." 推断:任何因为模板有而存在、而非因为内容需要的节拍。
6. 过程泄漏
诱因:模型会把自身产出过程的接缝留在成品里,比如聊天语气、评审历史和交叉引用。 测试:如果这份文档一直就是完成态,这段文字还会存在吗? 禁用:"per review feedback"、"as mentioned above"、"I hope this helps"、"Now also handles ..."、残留在代码注释中的对话痕迹。 示例:"// Now also handles empty arrays (per review feedback)" -> "// Empty arrays return zero." 推断:任何关于文本如何写成的痕迹,而非它说了什么。
上下文规则
散文:
- 先说具体事实,不要铺垫。
- 变化句子长度。警惕习惯性出现的三段式和首语重复。
- 删掉评价性而非度量性的副词。
- 一个想法只用一个比喻,弃用已经死掉的比喻。
- 读一下结尾。如果只是重复,就停在最后一个真正的点上。
文档:
- 开头写清楚这个东西做什么,或者怎么运行它。
- 优先用祈使语气(“运行 X”而不是“你可以运行 X”)。
- 没有哪个功能配得上它没挣来的好处尾巴。
- 一个完整的示例胜过三句描述。
- 标题要写明内容,不要用“概述”这类填充词。
PR 和提交文本:
- 主题要按变更本身来陈述,让没见过计划的人也能读懂。
- 不要计划标签、阶段编号,或只有本次会话才能解析的引用。
- 去掉表演式的工程俚语。写清楚实际机制。
- 只有在主题承载不了原因时才加正文。
代码注释(先过必要性关卡):
- 注释必须说出代码无法显示的内容。如果代码已经显示了,就删掉注释。
- 不要横幅或分隔线注释。不要给自解释的行加标签注释。
- 不要在字面量旁边重复它的值。
- 注释里不要有审查历史或对话残留。
- 写代码做什么,不要写它不做什么。只有当 “, not X” 或 “, no X either” 这样的尾巴能预防读者真会产生的误读时,才保留。
- 用真正的连接词连接从句。两个从句之间只用一个逗号会掩盖 and、so 或 but。写出连接词,或者拆成两句。
学术:
- 保留承载真实不确定性的模糊表述。删掉只为软化的模糊表述。
- 引用具体的研究、样本和发现,不要写“研究表明”。
- 平实的语域胜过拔高的词汇。直接陈述论点。
- 自造术语在首次使用时用平实的话定义。
剂量规则
任何单一模式出现一次也许没问题(机械性家规除外)。 多个模式同时出现,或一个模式反复出现,就是失败模式。 写得多样、具体、平实。