automate-me

Automate me

一套引导式流程，将用户的工作习惯转化为 Agent 会遵循的技能。输出为一个专为用户定制的 -mode 技能（例如 jay-mode、priya-mode）。

此技能会协调另外三项技能：内联挖掘流程（见步骤 1）、Cursor 内置的 create-skill（编写）以及 unslop 技能（规范文风）。它负责串联这些技能，而非取代它们。

流程

0. 检查是否已有技能

递归查找 .cursor/skills/**/*-mode/SKILL.md 和 ~/.cursor/skills/*-mode/SKILL.md，匹配用户的用户名。模式技能可以放在个人分类目录（.cursor/skills/<handle>/）中，而不只是顶层目录。如果已存在，请使用 AskQuestion 确认用户的意图（除非用户已经说过“更新我的技能”或类似的话）：

• 更新现有技能（重复运行时的默认选项）
• 重新开始（较少见，操作前先询问原因）

更新模式会改变后续流程：

• 步骤 1 只挖掘技能上次编辑之后的历史记录（git log -1 --format=%cI <path>）。
• 步骤 2 询问有哪些变化或缺失，而不是从零开始询问要记录什么。
• 步骤 4 在原文件中编辑。保留用户未提出异议的章节；根据新证据修订相关内容。仅在确实有新规则时添加新章节。

1. 挖掘用户的历史记录

在展开并行任务前，先定位当前工作区的对话记录。系统提示会指出工作区的 agent-transcripts/ 目录。仅使用该路径。不要对 ~/.cursor/projects/*/ 执行 glob 搜索。这样会跨越工作区边界，读取其他项目中的私人聊天记录。

在此范围内调查近期的 Agent 对话，寻找反复出现的模式。针对不同时间段并行运行多个子 Agent（例如，查看过去 2–4 周的记录，分成 3 个时间段，确保每段都有足够的材料）。每个负责挖掘一个时间段的子 Agent 都应读取父 Agent 提供的工作区范围路径，寻找以下信号，并以简短的结构化列表返回发现的模式及证据指针。默认值得寻找的信号：

• 回复偏好（长度、语气、格式、“说简单点”之类的纠正）
• 委派习惯（子 Agent、模型、专用工作流、并行处理）
• 验证倾向（怎样才算“完成”、单元测试还是实际复现、审查者）
• 代码与文风规范（风格、引用的原则、lint/格式化工具）
• 流程约定（worktree、提交、PR、审查/合并工具）
• 元偏好（任务中途修复技能、提议新增技能）

在总结信号前，对照各时间段的发现。至少在 2 个时间段出现的模式可信度较高。只在一个时间段出现的信号可信度较低，通常应舍弃。

2. 直接询问用户

挖掘无法发现用户尚未表达的意图。使用 AskQuestion 工具（结构化多选），而不是让用户从头开始输入。

形式：提出 1–2 个问题，每个问题提供 4–6 个选项；对于类别问题，将 allow_multiple: true。先从宽泛问题开始（“哪些方面对你最重要？”），再针对用户选中的方面提供具体选项。完成结构化问答后，再提出一个开放式聊天问题，以捕捉选项未涵盖的内容。

不要一次抛出 20 个问题。

3. 整理发现

将合并后的信号归入不同章节。常见章节如下（只使用适用的章节）：

• 回复风格：长度、语气、格式。
• 自主性：无需询问即可完成多少工作、MCP 工具的使用。
• 先理解再行动：确定变更范围或调查变更时应使用哪些技能。
• 子 Agent：默认设置、并行处理、模型与任务的匹配、专用工作流。
• 文风 / 代码规范：原则、lint 工具、风格指南。
• 审查与验证：复现倾向、验证技能、实时测试工具。
• 流程：Git worktree、提交、PR、审查/合并工具。
• 技能：技能编写习惯、先修复技能、提议新增技能。

poteto-mode 技能展示了章节结构。阅读它以了解颗粒度，但不要照搬其中的内容。用户的规则与 poteto-mode 的规则并不相同。

4. 起草技能

使用 Cursor 内置的 create-skill 技能编写该技能。放置位置：

• 路径：保留现有模式技能的类别。对于新模式，如果仓库已为该标识符建立个人类别，则使用 .cursor/skills/<handle>/<handle>-mode/SKILL.md。否则，默认放在项目的 .cursor/skills/<handle>-mode/SKILL.md（如果用户希望使用个人技能，则放在 ~/.cursor/skills/<handle>-mode/）。
• 标识符：用户的名字或其选择的标识符。
• Frontmatter 中的 description：设置为用户名字 + /<handle>-mode +“按他们的风格工作”时触发，不要使用“编写代码”或“审查 PR”这类通用关键词。
• Frontmatter 格式：遵循 create-skill 的 YAML 规则。将 description 写成单个 YAML 标量。如果标点或换行需要，可为其加引号，或使用 description: >- 并在后续行缩进。
• 默认设置 disable-model-invocation: true。只有在用户明确希望该模式每轮都生效时才不采用此设置。

5. 反复打磨文案

对每一行应用 unslop 技能和 create-skill 的写作指南。

向用户展示草稿并征求反馈。预计需要多轮修改。大刀阔斧地删减。模式技能不是手册。

6. 合入

在基于 main 创建的 worktree 中操作。提交更改并创建 PR。不要直接推送到 main。

防护准则

• 不要过度适配单次对话。 某项偏好只提过一次，且另一次表达了相反意见，就属于噪声。需在多次出现后才将其写入技能。
• 不要自作聪明。 重述其他技能的内容、编造比喻，或为 Agent 读者写“诗意”的文案，都是无益的成本。保持操作性。
• 引用，不要内嵌。 用户依赖的其他技能应以路径引用的形式出现，而不是粘贴内容。其他位置维护的原则文档也一样。
• 精简章节。 只有用户在某个方面有明确且非默认的规则时，才添加相应章节。“清晰沟通”不算一个章节。“段落简短。比较选项时使用表格。仅在条目确实并列时使用项目符号。”则算。
• 命名约定应通用。 在指令中使用“用户”或“人”，不要使用作者的名字。
• 不要强求对称。 如果用户没有值得记录的流程规则，就完全省略“流程”章节。

评估

-mode 技能的输出具有主观性。create-skill 风格的测试／迭代基准循环在此并不适用。与用户一起进行直观评估：读起来像他们的风格吗？有没有遗漏？然后发布。

只有当技能的触发准确率在实际使用中出现问题时，才运行描述优化循环。

何时不应使用

• 用户想要的是针对特定任务的技能（而非工作惯例）：只使用 create-skill，无需挖掘。
• 用户想要记录一个范围较窄的工作流（例如“我如何撰写提交消息”）。这属于常规技能，不是模式技能。