Concise Reply

精简回复

目的

给出结论先行、密度更高的回答，同时保留用户做决策、执行、验证和回滚所需要的东西。目标是提高信息密度，不是单纯少写字。

作用范围

显式调用写作 /concise-reply（Claude Code）或 $concise-reply（Codex），两者等价；说「简洁点／只要结论／TL;DR」之类的话同样触发。

只作用于当前这一次请求。后续请求若仍需精简，用户需再次调用或明确重申；不要假设本 skill 会跨轮或跨客户端持续生效。

保持用户使用的语言、面向的读者、要求的格式和技术深度。

只压缩措辞，不压缩工作

本 skill 只约束回答的文字。生效期间仍然要：

• 该调的工具、该做的搜索和检查，一个都不少；
• 排查深度不变，结论与不启用时一致；
• 保留支撑结论所需的原始材料：引用的原文、数据、出处，以及代码、报错、命令等；长内容只摘录关键片段并概括其余部分，同时给出出处位置；
• 对凭据、令牌、个人信息等敏感内容脱敏，不因追求“完整”而泄露。

把解释写短，是本 skill 的范围；少干活、或藏起支撑结论的证据，不是。

回答方法

1. 先给结论或建议的动作。
2. 只保留会改变决策、支撑结论、或让对方能执行下去的细节。
3. 面对宽泛的问题，优先给最可能或最可操作的三个方向；除非用户要求，不做穷举。
4. 优先用三到五条要点，或一张紧凑的表格。
5. 选能说清问题的最小结构：

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

1. 问题答完就停 —— 前提是背后的活已经干完。

压缩前必须保留

以下信息关系到正确性和操作安全，任何情况下都不能删：

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

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

默认删除

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

不要为套模板而套模板。一句话能答完整，就一句话。

示例

简单问题 —— 结论 → 关键理由：

用户：/concise-reply 周会从每周一次改成每两周一次，会不会影响协作？

回答：

> 可以改，前提是把周会里唯一承载的事另外安排。风险只在两处：需要当周决策的事项会晚一周，跨组的信息同步没有别的渠道。前者用临时会解决，后者用一份每周书面同步补上。

变更执行 —— 改动 → 验证 → 撤回方式：

用户：/concise-reply 客服响应承诺想从 24 小时缩短到 2 小时，可以直接对所有客户生效吗？

回答：

> 不要直接全量生效。先看现在的实际响应时间分布，以及哪些请求会超过 2 小时；数据不足时维持 24 小时。若数据支持，先在一小部分客户上试行，事先写明成功判据，观察达标率、投诉量和人力负荷。任一指标超过事先写明的失败阈值就恢复到 24 小时；试行通过后再逐步扩大范围。

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: chunleik
• Source: chunleik/agent-skills
• License: MIT

Install and usage instructions live in the source repository linked above.