精简回复

先说问题

常规长回复常见的失败不是信息不够，而是信号被噪声淹没：复述提问、套话开场、把同一结论换三种说法，最后再来一段结尾总结。真正影响决策的条件——假设、验证方式、回滚步骤——反而夹在中段，需要自己翻。

更糟的是，有些回复把"写得短"理解成"少干活"：减少工具调用、跳过检查、只给结论不给证据。结果短是短了，但没法执行，也没法验证。

concise-reply 处理的是前一种问题，且明确拒绝后一种做法。

它如何工作

核心原则一句话：提高信息密度，不是单纯少写字。

• 结论先行：第一句直接给结论或建议动作，之后才是理由。
• 只压缩措辞，不压缩工作：该调的工具、该做的搜索和检查一个不少；排查深度不变，结论与不启用时一致。
• 证据不删，只摘录：引用原文、数据出处、代码、报错、命令保留；长内容摘录关键片段、概括其余，并给出出处位置。
• 敏感信息脱敏：凭据、令牌、个人信息默认打码，不因追求"完整"而泄露。

回答时按请求类型选最小结构：

• 简单问题 → 结论 → 关键理由
• 查找原因 → 判断 → 依据 → 验证 → 下一步
• 方案选型 → 推荐 → 取舍 → 风险
• 变更执行 → 改动 → 验证 → 撤回方式
• 证据不足 → 当前判断 → 缺哪些证据 → 最小验证动作

宽泛问题优先给最可能或最可操作的三个方向，不做穷举。优先用三到五条要点或一张紧凑表格。一句话能答完整，就一句话，不为套模板而套模板。

适用边界与注意点

任何情况下都不能删的信息：

• 假设、前置条件和不确定性
• 破坏性操作、安全、兼容性、隐私、数据丢失风险
• 验证方式和成功判据
• 失败后果严重时的回滚或恢复步骤

简洁与安全、准确冲突时，安全和准确优先。要删的是重复，不是限制条件。

默认删除的内容：复述提问、套话开场和恭维；目标读者本来就该知道的背景；重复的理由、结论和步骤清单（包括结尾又把答案说一遍的总结段）；首轮结果出来之前的次要分支；不影响下一步的小标题和跑题内容。

作用范围：只作用于当前这一次请求。后续请求若仍需精简，需再次调用或明确重申，不要假设本 skill 会跨轮或跨客户端持续生效。保持用户使用的语言、面向的读者、要求的格式和技术深度。问题答完就停——前提是背后的活已经干完。