回复像我的风格
以用户写给别人的方式写作，而不是以助手的方式写作。
此技能用于面向人的消息：聊天、回帖、电子邮件和公告。切勿将其用于技术文档（RFC、规格说明、ADR、设计文档、操作手册）、拉取请求、代码审查评论、提交消息或代码。这些文档应遵循其所在仓库自己的写作规则。如果一条面向人的消息链接了上述文档之一，则用用户的语气写消息，而链接的文档保持原样。
技能包含方法。语音档案存在于用户机器的配置文件目录中，位于技能本身和任何仓库之外，因为它是由用户的私人消息构建的：
- 档案文件夹：如果设置了
$REPLY_LIKE_ME_DIR，则使用该路径，否则使用~/.config/reply-like-me/。 - 文件夹包含的内容以及每个文件的编写方式： references/profile-format.md
语音档案必须保留在用户自己的机器上。切勿将其或 raw/ 文件夹中的任何内容写入仓库或共享文件夹。如果您在云或远程虚拟机上运行，而不是在用户的计算机上，请不要运行设置：说明需要本地会话。
选择模式
- 用户要求设置或刷新，或者档案文件夹中没有
voice.md：运行设置。遵循 references/setup.md。如果用户要求草稿但没有档案，请说明情况并提供设置选项，然后再起草任何内容。 - 用户要求“从我编辑的内容学习”或“从我发送的内容更新”：对每个打开的草稿运行 references/learning.md，然后汇报学到的经验。
- 否则，起草。
起草
- 首先从早期的草稿学习：检查
drafts/中的打开草稿，并将其与用户发送的内容进行比较，如 references/learning.md 所述。保持快速：只需搜索过去3天的草稿。 - 阅读
voice.md、chat-examples.md，如果存在，则阅读people.md。对于长帖或公告，如果存在，也阅读docs-examples.md：它展示了他们如何写长文本。如果存在，阅读corrections.md。它的规则优先于档案中的所有其他内容。 - 阅读您正在回复的帖子或文档，以便回复符合已经说过的话以及是谁说的。如果没有，则根据用户提供的内容进行起草，并为您不知道的事实留下
[占位符]。 - 以用户的语气起草。真实示例优先于规则：当两者不一致时，遵循示例。
- 执行
voice.md末尾的检查清单，然后执行下面的检查。 - 展示草稿并将其记录到
drafts/中，注明去向。如果用户在此处发送前编辑了它，请立即从编辑中学习。无论哪种方式，下一次运行时都会将其与用户发送的内容进行比较，并将经验记录在corrections.md中。
无论档案说什么都适用的规则
- 默认情况是草稿。 展示草稿，或将其保存为相应工具中的草稿。仅当用户要求发送时才发送。
- 仅代表用户已经说过或决定的内容发言。 不要同意截止日期、批准工作、承诺付款，或给出用户未给出的意见或建议。留一个
[建议]占位符并询问。 - 不要否认自己是AI。 如果有人问这是否是Claude、Cursor或其他AI助手写的，请如实回答。
- 切勿替他人回复。 如果消息中@了另一个人，请留给他们自己。
- AI撰写的消息不是用户的语气。 用户以“使用XX助手发送”为结尾的消息，或读起来像AI润色过的（带有em破折号、整洁的段落、AI常用词汇）消息，并非用户本人所写。切勿复制其措辞，即使是在您正在回复的帖子中。
- 以用户称呼人的方式称呼他们。 非正式的称呼（“mate”、“dude”、“love”、“bro”、昵称）仅用于
people.md中至少列出三次的人。使用一两次可能是误读了帖子，因此视为未确认。未列出的人使用其名或不使用。切勿根据某人的名字、照片或假定的性别来决定使用哪个称呼。 - 一个反应可以作为回复。 如果回复只是表示“已读”、“批准”、“谢谢”或“在做了”，则建议使用档案中给出的相应反应，而不是起草消息。
- 不要编造错别字。 按照档案给出的频率使用用户的习惯（小写、缺少句号、省略撇号），但虚假的拼写错误读起来会显得虚假。
- 不要使用他们不用的习语。 从档案中提取短语，而不是从标准英语中。
- 对于以用户身份发送的文本，用户的语气优先于一般的写作风格规则，除非
voice.md说明某条规则仍然适用。