concise-copy

精简文案命令

精炼文案或文档，让文字直截了当、高效明了。

规则

• 删除赘词：删去“应该”“必须”“……的过程”“……的能力”等表述。
• 从动作或状态开始：不要写“- 系统应该支持 X”，改写为“- X”。
• 直接表达：使用主动语态，尽量精简措辞。
• 避免冗长：一个概念能用 3 个词而不是 10 个词表达时，就用 3 个词。

审批讨论应考虑移除，而非精简

有时，文档中最冗长的段落记录了一场讨论：谁批准了某项内容、考虑过什么又否决了什么，以及经过怎样的来回讨论才形成一条规则。这不是冗长问题，精简它也不是正确做法——按照 approval-policy 技能的要求，这类内容可能根本不该出现在已提交的文件中。它更适合放在 PR、问题跟踪项或决议评论中。

这类内容通常包括：approved by …、we decided …、we considered X but …、as discussed …，叙述讨论过程而不是直接陈述规则的理由段落，以及解释为何修改早期版本的说明。

如果有人正在键盘前操作——也就是说，对方最近几轮发过消息，而本次运行正在回复对方——请先询问，再处理此类段落。只问一个问题，提供三个选项：移除（内容留在跟踪项中）；先移到跟踪项，再移除；或原样保留，因为此文件正是它应当存放的位置。

如果对方不在，就不要询问，也不要删除。 长时间无人值守的运行、定时任务、跨多个文件的批量处理，或自另一个技能触发且期间没有人工消息的任务——没人能回答的问题会让整个任务停下来，这比保留一段文字更糟。原样保留该段落，并在输出中列出发现的每一处，供人工之后决定。

无论如何，都不要默默地把它当作赘词删掉。 将记录压缩到信息变少，是此技能绝不能擅自进行的编辑：移除记录关乎记录应存放在哪里，而非如何精简文字。

示例

修改前：

• 导入过程应该支持 不完整数据状态（例如处于“草稿”阶段，有会话但没有房间分配）。

修改后：

• 不完整数据状态（例如，草稿会话 -> 无房间分配）。