用途
cursor-automate-me 是一个引导式流程，用于把用户的工作约定转化为一个智能体会遵循的技能。输出是一个为用户量身定制的 -mode 技能（例如 jay-mode、priya-mode）。
它本身不替代其他技能，而是编排三个技能：一个内联的挖掘流程（见步骤 1）、原生的 skill-creator（负责撰写）以及 cursor-unslop 技能（负责文风纪律）。它只负责排序调度。
主要能力与流程
0. 检查是否已存在技能 递归查找 .agents/skills/**/-mode/SKILL.md，以及个人 Codex 技能根目录（~/.codex/skills/-mode/SKILL.md，在相关且可读时）中与用户 handle 匹配的文件。Mode 技能可以放在个人分类目录（.agents/skills/<handle>/）中，而不只在顶层。如果已存在，通过原生可选的用户输入界面确认意图（除非用户已经说了“更新我的技能”之类的话）：更新现有技能（重复运行时的默认选项）或从头开始（少见，做之前先问原因）。
更新模式会改变后续流程：步骤 1 只挖掘技能上次编辑以来的历史（git log -1 --format=%cI <path>）；步骤 2 询问有什么变化或缺失，而不是从零开始捕获；步骤 4 就地编辑现有文件，保留用户未否定的章节，根据新证据修订章节，只为真正的新规则添加新章节。
1. 挖掘用户历史 在展开之前先定位当前工作区的对话记录。只使用当前工作区提供的对话记录路径或原生任务历史访问。不要跨不相关的任务根目录做 glob，那会跨越工作区边界并读取无关项目的私密对话。
在该范围内调查最近的智能体对话，寻找重复出现的模式。跨历史切片并行运行多个子智能体（例如最近 2-4 周，切成 3 个切片，使每个都有足够素材）。每个切片挖掘子智能体读取父级提供的工作区范围内路径的对话记录，寻找以下信号，并返回一份带证据指针的简短结构化模式列表。默认值得寻找的信号：
- 回复偏好（长度、语气、格式、“说简单点”之类的纠正）
- 委派习惯（子智能体、模型、专门工作流、并行）
- 验证姿态（“完成”意味着什么、单元测试还是实机复现、审查者）
- 代码与文风纪律（风格、引用的原则、lint/format 工具）
- 流程约定（worktree、提交、PR、审查/合并工具）
- 元偏好（任务中途修技能、提议新技能）
在提升某个信号之前先跨切片交叉核对。在 2 个及以上切片中出现的模式是高置信度的。孤立信号较弱，通常会被丢弃。
2. 直接询问用户 挖掘会遗漏尚未出现的意图。使用原生可选的用户输入界面做简洁选择，用其自由文本路径补充缺失内容。形式：一到两个简洁问题，附带宿主支持的选项；如果没有多选，则在后续轮次或自由文本中收集优先级。先宽泛（“哪些方面最重要？”），再针对选定领域用具体选项追问。结构化轮次之后，用一个自由形式的聊天问题捕捉选项遗漏的内容。不要抛出 20 个问题。
3. 聚类发现 把合并后的信号分组为章节。常见章节（只使用适用的）：回复风格（长度、语气、格式）；自主性（不问就做多少、MCP 工具使用）；先理解（界定或调查变更时该用哪些技能）；子智能体（默认、并行、模型到任务、专门工作流）；文风/代码纪律（原则、lint 工具、风格指南）；审查与验证（复现姿态、验证技能、实机测试工具）；流程（git worktree、提交、PR、审查/合并工具）；技能（技能撰写习惯、先修技能、提议新技能）。cursor-poteto-mode 技能展示了形态，可读它了解粒度，但不要复制其内容——用户的规则与 cursor-poteto-mode 的不同。
4. 起草技能 使用原生 skill-creator 技能撰写。放置位置：路径上保留现有 mode 技能的类别。对于新 mode，当仓库已为该 handle 建立了个人分类时，使用 .agents/skills/<handle>/<handle>-mode/SKILL.md；否则默认使用项目中的 .agents/skills/<handle>-mode/SKILL.md（或 ~/.codex/skills/<handle>-mode/，如果用户偏好个人技能）。Handle 用用户的名字或选定的标识符。Frontmatter 的 description 应以其名字 + /<handle>-mode + “按他们的风格工作”为触发条件，而不是“写代码”或“审查 PR”这类通用关键词。Frontmatter 格式遵循 skill-creator 的 YAML 规则，description 保持为单个 YAML 标量，需要时用引号或 description: >- 加缩进续行。Frontmatter 的 disable-model-invocation 默认设为 true，只有当用户明确希望其 mode 在每一轮都生效时才选择退出。
5. 迭代文风 对每一行应用 cursor-unslop 和 skill-creator 的写作指南。把草稿给用户看并收集反馈，预期多轮迭代。无情删减——mode 技能不是手册。
6. 落地 在基于 main 的 worktree 中工作，提交并开 PR，不要直接推送到 main。
适用场景
用户说“automate me”“创建/更新/刷新我的 -mode 技能”“把我的偏好或工作风格变成技能”，或希望智能体遵循其工作方式时。
限制与护栏
- 不要过拟合单次对话。只出现一次又被另一次否定的偏好是噪声，需要多次出现才可固化。
- 不要耍聪明。复述其他技能内容、发明隐喻或为智能体读者写“诗意”文字是只有成本没有收益，保持可操作。
- 引用而非内联。用户依赖的其他技能应以路径引用出现，而不是粘贴摘录；用户在其他地方维护的原则文档同理。
- 保持章节最小。只有当用户在该处有具体、非默认规则时才添加章节。“清晰沟通”不算章节，“短段落。比较选项时用表格。仅当条目真正并列时用项目符号”才算。
- 命名约定保持通用。在祈使句中使用“the user”或“the human”，而不是作者的名字。
- 不要强求对称。如果用户没有值得写下的流程规则，就完全跳过 Process 章节。
评估
-mode 技能是主观输出，skill-creator 式的测试/迭代基准循环在这里没有用。与用户做感觉检查：读起来像他们吗？漏了什么吗？然后发布。只有当技能的触发准确性在实践中成为问题时，才运行 description 优化循环。
何时不使用
- 用户想要任务特定技能（而非工作约定）：只用 skill-creator，无需挖掘。
- 用户想捕获一个狭窄工作流（例如“我如何写提交信息”）：那是普通技能，不是 mode 技能。