用途：把计划、Markdown、注释、JSDoc 和面向用户的字符串改写成技术读者能跟随的散文，保留含义与结论，不重构代码，不添加“灵魂”。若需对 git 分支做编排式清理（TypeScript、Zod、shims、location，再对 diff 中的注释/文档做此处理），使用 unslop-code。
主要能力与原则：长度不是指标，删冗余，把省下的词用在读者尚不知道的内容上，不填充，不用标签回答“这是什么”。绝不用更顺的句子换掉事实：保留每个版本号、文件路径、脚本名、结论和阈值。保留锚点，引用文件、固定 permalink 或行范围代码块，便于读者核对。结构上先写当前状态或事物本身，再按选项分节，每个选项给出可见结论（现在做/试试/以后/不做，或一行建议）加理由；流程用简短 mermaid 图优于段落。区分已验证、评估与开放问题：计划中标注“仓库中已验证”“假设”“需决策”；研究中保留 FAKT/EINSCHÄTZUNG/UNSICHER 或文档语言的对应词。句子一义一句，先因后果，点明主体，优先机制而非感受。表格仅在同列时使用，承载“是什么/为什么/权衡”时拆成小节。一个概念一个名称，定义一次后重复，不循环同义词。
需删除的表达：复述下一行的注释、浮夸词（crucial/robust/comprehensive）、表面 -ing 从句、无来源的“专家/最佳实践”、AI 词汇（delve、pivotal、landscape、tapestry、leverage、utilize）、“不只是 X 而是 Y”、强行三连、破折号、句中冒号拐杖、每个专有名词加粗、标题式大写、装饰性 emoji、弯引号、聊天机器人套话、填充语、堆叠模糊限定、抽象隐喻名词、可原样粘贴到其他仓库的句子。代码中删除复述下一行的注释和只重复名称的 JSDoc，保留代码无法表达的约束（带链接的 MapLibre/React 怪癖、法律说明、编译器无法表达的类型）。
语气：干、具体；用户要求时匹配其语气（GitHub issue、给维护者的邮件），保留文档语言，改写德语时不要译成英语。不要悄悄改变实质：措辞调整若暴露错误或夸大，应单独说明而非埋进改写。聊天回复的摘要也遵循本技能；若聊天摘要比文档更清晰，要修的是文档。
限制：资料未提供安装命令、平台、收费或价格信息；不重构代码，不添加个人色彩或观点纹理。