automate-me

自动化我

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

这项技能会协调另外三项技能：内联挖掘流程（见步骤 1）、Cursor 内置的 create-skill（编写技能），以及 unslop 技能（规范文风）。它负责安排执行顺序，不会取代它们。

流程

0. 检查是否已有技能

递归查找符合用户 handle 的 .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 段，确保每段都有足够材料）。根据 poteto-mode 技能的 Subagents 部分，为每个子 Agent 选择适当的推理级别，以及快速或标准速度。每个负责挖掘一个时间段的子 Agent 都应读取父 Agent 提供的工作区范围路径，查找以下信号，并返回简短、结构化的模式列表及证据指针。默认值得关注的信号：

• 响应偏好（长度、语气、格式、“说简单点”之类的纠正）
• 委派习惯（子 Agent、模型、专用工作流、并行处理）
• 验证方式（如何判定“完成”、单元测试还是实际复现、审查者）
• 代码和文风规范（风格、引用的原则、lint/格式化工具）
• 流程惯例（工作树、提交、PR、审查/合并工具）
• 元偏好（任务进行中修改技能、提议创建新技能）

在提升某个信号的优先级之前，先交叉核对各时间段的结果。至少在 2 个时间段中出现的模式可信度较高。只出现一次的信号可信度较低，通常应舍弃。

2. 直接询问用户

挖掘无法获知尚未出现过的意图。使用 AskQuestion 工具进行结构化多选，而不是让用户从头输入。

形式：提出一到两个问题，每个问题提供 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: >- 并缩进续行。
• Frontmatter disable-model-invocation: true 默认开启。只有用户明确要求其模式在每轮对话中都生效时，才关闭此设置。

5. 迭代润色文案

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

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

6. 合并

基于 main 在 worktree 中进行开发。提交并创建 PR。不要直接推送到 main。

护栏

• 不要过度拟合单次对话。 某项偏好只被提及一次，且与其他情况矛盾时，应视为噪声。只有多次出现才将其编入规则。
• 不要耍小聪明。 复述其他技能的内容、编造比喻或为 Agent 读者写“诗意”文案，都是徒增成本。保持可操作性。
• 引用，不要内嵌。 用户依赖的其他技能应以路径引用的形式列出，而不是粘贴其内容。用户在其他位置维护的原则文档也应如此。
• 精简章节。 只有当用户在某方面有明确的非默认规则时，才添加相应章节。“清晰沟通”不算章节。“段落简短。比较选项时使用表格。只有在各项确实并列时才使用项目符号。”则可以。
• 名称约定应通用。 在指令中使用“用户”或“人类”，而非作者的名字。
• 不要强求对称。 如果用户没有值得记录的流程规则，就完全跳过流程章节。

评估

-mode 技能的输出具有主观性。在这里，create-skill 风格的测试 / 迭代基准循环并不实用。请与用户一起进行直观评估：读起来像用户本人的风格吗？有没有遗漏？然后交付。

只有在实践中发现触发准确度有问题时，才进行描述优化循环。

不适用场景

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