菜单
每当用户要求编写、重写、缩短、澄清、审查、润色、重构或改写文档及任何面向人类的说明性文本时，请使用本技能。对于任何创建或修改文档的任务，还要使用 clean-agent 协调模式，使创建者和审查者 SubAgent 将 clean-doc 作为共同的沟通规范。它把信息转化为针对特定受众和决策情境的目标导向型沟通，优先考虑读者的语言和风格，并且只保留与决策相关的信息。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
当生成或探索性工作可能失败、需要多次尝试、涉及众多约束、需要验证，或会产生不应污染主 Agent 上下文的中间发现时，主动使用本技能。 本技能运行一个整洁的主智能体循环：主 Agent 只负责协调，将上下文导出到文件，派发创建者/审查者 SubAgent，将重试过程留在主上下文之外， 并且只接收工件路径以及 PASS / RETRY / FAILED 审查说明。
用于每一项编程任务，以控制流程复杂度。对于任何创建或修改代码的任务，还应使用 clean-agent 协调模式，让创建者和审查者 SubAgent 将 clean-code 作为共同的代码规范。它强制执行复杂度门禁，将每个分支视为新增的逻辑路径，要求有明确的业务理由，尤其适用于实现和代码审查。
强制执行 CZ 的 Git 和 GitHub 交付风格，包括 gitmoji 提交、受保护的 main、仓库本地 worktree、仅 Squash 的 Auto Merge、拉取请求监控、GitHub Actions 验证和安全清理。每当 Codex 设置或更新 GitHub 仓库、创建功能 worktree、准备或发起拉取请求、跟进拉取请求直至合并并完成 Actions，或执行相关 Git 工作流时，都应使用本技能。
当代码运行缓慢、超时、被终止、消耗大量 CPU、执行长时间批处理作业、进行参数扫描、训练模型、处理大型数据集、运行模拟，或目标规模运行时间未知时，使用本技能。它指导智能体逐步探测运行时间，在可行时进行在线 N-T 进度插桩，采用固定超时采样，执行 N-T 扩展估算，并在尝试目标规模前作出全规模运行的通过/不通过决策。如果进行了优化，它要求保留慢速版本的规范输出，证明语义逐字节等价，并在通过并行投入更多 CPU 前优先消除无效工作。本技能不封装性能分析工具，也不提供通用优化方案；它负责判断应全规模运行、停止，还是转入性能分析和原则性优化。
当任务涉及困难推理、原因不明、无法解释的观测、失败的假设、模糊诊断、复杂系统、涌现行为、调查规划，或当前解释空间不完整的任何情形时，请使用此技能。此技能应用递归残差推理：将尚未解释的内容保留为显式残差，把该残差扩展为下一个推理空间，并生成一条从观测到结论、行动或有界停止原因的可追踪路径。
当创建、修改、解释、诊断或验证模型、规则、评分系统、预测、参数选择、机制假设或研究结论时，请使用此技能。它要求同时具备先验依据与实证验证来评估可靠性，并区分可靠结论与黑箱相关性、空洞叙事、事后线索及不可靠主张。
| name | clean-doc |
| description | 每当用户要求编写、重写、缩短、澄清、审查、润色、重构或改写文档及任何面向人类的说明性文本时，请使用本技能。对于任何创建或修改文档的任务，还要使用 clean-agent 协调模式，使创建者和审查者 SubAgent 将 clean-doc 作为共同的沟通规范。它把信息转化为针对特定受众和决策情境的目标导向型沟通，优先考虑读者的语言和风格，并且只保留与决策相关的信息。 |
Clean Doc 帮助将文本转化为针对特定读者、情境和预期效果的高效沟通。目标不是保留所有可用信息，而是帮助读者理解要点、决定如何行动，并以适当的信心采取行动。
对于任何创建或修改文档及其他面向人类文本的任务，要求主 Agent 使用 clean-agent 协调模式。将 clean-doc 保持为领域关卡：把它作为同一份共享规范传给创建者和审查者。让 clean-agent 负责角色分离、审查、重试和升级；不要用编排规则取代本技能的沟通标准。
只有当任务明确指派 clean-agent 创建模式或审查模式，并提供相同的共享规范来源以及适用的工件路径或审查约定时，才将当前角色视为已经处于 clean-agent 循环中。此时直接执行该角色，不要派发其他 SubAgent，也不要启动嵌套循环。仅仅身为 SubAgent、收到委派任务或被要求编写文件，并不足以获得这项豁免。
只有当任务不创建或修改工件时，才直接对只读说明或评论应用 clean-doc。
高信息密度的写作取决于读者以及文档必须完成的工作。编写或编辑之前，请确定：
读者是谁？
他们处于什么情境？
文档应促成什么决策、行动或理解？
他们已经知道什么，又需要澄清什么？
哪些信息会改变他们的判断或行为？
如果无法从提示词或周围上下文推断答案，请提出一个简洁的澄清问题。如果上下文足够清楚，请按最可能的读者和目的继续，并在输出中体现这一选择。
默认使用用户的母语和惯用语言风格。这一点很重要，因为目标导向型写作不仅关乎信息选择，还要让读者容易接收、信任信息并据此行动。
遵循以下规则：
不要假设特定行业、工作流、研究流程、指标体系或组织文化。本技能可支持工程文档、产品规范、内部备忘录、公开公告、政策、入门材料、事后分析、战略说明、教程、提案、报告、电子邮件及其他面向人类的文本。
当周围上下文定义了领域特定的写作方案时，请采用它。上下文可能定义：
上下文应使写作计划具体化；但不应推翻一个核心原则：文档存在的目的是服务于读者的决策、行动或理解。
定义接收者。 确定读者、他们的情境，以及他们读完后需要做什么。
定义沟通任务。 判断文档应帮助读者做决策、执行、学习、审计、达成一致、排查故障、记忆、批准，还是继续向他人传达。
按影响选择信息。 保留会改变读者判断、行动、风险认知或理解边界的信息。压缩或删除仅仅让文档显得完整的信息。
先构建主路径。 尽早给出最有用的结论、指令、建议或框架。然后补充证据、约束、例外和后续步骤。
区分确定性层级。 区分事实、解释、假设、风险、未知事项和建议。不要把尚未解决或支持薄弱的材料表述为定论。
调整形式。 选择最适合任务的结构，而不是机械套用模板。
精炼表述。 删除重复内容，弱化不必要的术语，缩短冗长解释，并明确行动边界。
将此表作为起点，而不是固定模板。
| 文档目的 | 优先保留 | 压缩或删除 |
|---|---|---|
| 决策备忘录 | 建议、选项、权衡、风险、决策标准 | 完整历史、影响较小的上下文、修辞性铺垫 |
| 执行指南 | 步骤、前提条件、检查项、停止条件、示例 | 冗长背景、抽象动机、重复警告 |
| 设计文档 | 问题、目标、约束、方法、接口、权衡、验证 | 过早的实现细节、无关的替代方案 |
| 审查或评论 | 主要阻碍、证据、影响、具体修复措施 | 泛泛的赞美、详尽复述、模糊意见 |
| 入门材料 | 心智模型、关键概念、初始行动、常见陷阱 | 罕见边界情况、内部争论、过多政策细节 |
| 事故报告或事后分析 | 影响、时间线、原因、促成因素、修复措施、负责人 | 指责性语言、未加标注的推测、无关日志 |
| 公开更新 | 变更内容、重要性、受影响对象、所需行动 | 内部流程细节、无依据的声明、不必要的保留意见 |
| 提案 | 期望结果、理由、范围、成本、风险、请求 | 过长背景、隐藏假设、装饰性语言 |
同一事实在一份文档中可能是有效信息，在另一份中则可能是噪声。判断每一节是否能帮助处于当前情境的这位读者。
对于面向决策的写作，优先采用：
建议
为何重要
已考虑的选项
权衡
风险与未知事项
所需决策
后续步骤
对于面向执行的写作，优先采用：
目标
范围
前提条件
步骤
检查项
停止条件
故障排查
后续步骤
对于说明性写作，优先采用：
核心理念
为何重要
关键概念
示例
常见错误
如何应用
对于面向审查的写作，优先采用：
主要发现
影响
证据
建议的变更
开放问题
当用户要求特定格式，或文档目的表明其他形式更合适时，不要强行套用这些结构。
缩短或清理文档时，请依次执行以下步骤：
压缩后，确认读者仍能回答：
重点是什么？
为什么我应当关心？
接下来我该做什么？
哪些证据或约束很重要？
有哪些限制或不确定性？
审查现有文档时，首先指出最影响沟通效果的问题。重点关注：
然后在适当时提供具体编辑或重写版本。如果用户要求重写或修改文件，不要止步于抽象建议。
交付前，请检查：
目标读者是否明确？
预期的决策、行动或理解是否明确？
要点是否足够靠前？
是否删除了无助于当前目的的信息？
事实、假设、风险和建议是否分开？
语言对于用户和受众来说是否自然？
文档是否尊重领域上下文而不预设领域？
对话之外的人是否能充分理解结果并据此行动？
如果答案是否定的，请先修正结构，再润色措辞。
如果用户要求直接编辑，请执行编辑并简要总结变更。
如果用户要求审查，请先列出最重要的沟通问题，然后给出可执行的修复措施。
如果用户要求压缩，请说明压缩目标和保留标准，然后提供更短的版本。
如果用户要求编写新文档，请在写作前推断或询问受众、目的和期望结果。