automate-me

自动化我

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

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

流程

0. 检查是否已有技能

在项目的 .cursor/skills/ 或 ~/.cursor/skills/ 下查找与用户句柄匹配的 *-mode/SKILL.md。如果存在，请用 AskQuestion 确认用户的意图（除非他们已表示要“更新我的技能”或类似意思）：

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

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

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

1. 挖掘用户的历史记录

在并行展开任务前，先定位当前工作区的对话记录。系统提示中会给出该工作区的 agent-transcripts/ 目录。只能使用该路径。不要跨 ~/.cursor/projects/*/ 进行全局搜索，因为这会越过工作区边界，读取其他项目中的私人对话。

在限定范围内查看近期 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. 起草 skill

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

• 路径：项目中的 .cursor/skills/<handle>-mode/SKILL.md（如果用户更喜欢个人 skill，也可放在 ~/.cursor/skills/<handle>-mode/）。
• Handle：用户的名字或自选标识符。
• Frontmatter description：当用户的名字、/<handle>-mode 和“以他们的风格工作”同时出现时触发；不要使用“编写代码”或“审查 PR”等通用关键词。
• Frontmatter 格式：遵循 create-skill 的 YAML 规则。将 description 保持为单个 YAML 标量；如标点或换行需要，可加引号，或使用 description: >- 并缩进后续行。
• 默认设置 Frontmatter disable-model-invocation: true。Mode skill 内容繁多且风格鲜明；只有用户明确调用（通过名称或斜杠命令）时才应应用，不要因描述匹配而自动触发。只有用户明确要求每一轮都应用其 mode 时，才取消此设置。

5. 迭代打磨文案

对每一行都应用 unslop skill 和 create-skill 的写作指南。两者适用于任何供 Agent 阅读的文案，而不仅是 skill。

向用户展示草稿并征求反馈。预期会有多轮迭代。大刀阔斧地删减；mode skill 不是手册。

6. 完成并提交

基于 main 在 worktree 中开发。提交更改并创建 PR，供用户审查。不要直接推送到 main。

防护原则

• 不要过度拟合单次对话。 某个偏好只提过一次，且与其他时候的说法矛盾时，应视为噪声。需要多次出现后才能将其写入规范。
• 不要自作聪明。 复述其他 skill 的内容、编造比喻，或为 Agent 读者写“诗意”文案，都是徒增成本。保持可操作性。
• 引用，不要内嵌。 用户依赖的其他 skill 应以路径引用，而不是粘贴内容。用户在其他位置维护的原则文档也同样处理。
• 保持章节精简。 只有用户有特定的非默认规则时才添加章节。“清晰沟通”不构成一个章节。“段落简短。比较选项时使用表格。只有在条目确实并列时才使用项目符号。”才值得作为章节内容。
• 命名约定通用化。 在祈使句中使用“用户”或“人类”，不要使用作者的名字。其他人也可能阅读或采用此 skill。
• 不必强求对称。 如果用户没有值得记录的流程规则，就完全省略 Process 章节。精简无妨，臃肿则不行。

评估

-mode skill 的输出具有主观性，因此 create-skill 风格的测试／迭代基准循环在这里并无用处。与用户一起检查是否合适：读起来像他们吗？有没有遗漏？然后交付。

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

何时不使用

• 用户想要的是针对特定任务的 skill（而非工作约定）：只使用 create-skill，无需挖掘偏好。
• 用户想记录一个狭窄的工作流（例如“如何撰写提交消息”）：这是常规 skill，而非 mode skill。

参考文件

• poteto-mode skill：输出形式示例。
• unslop skill：适用于每一行的文案规范。
• Cursor 内置的 create-skill skill：skill 编写流程和写作指南。