automate-me

自动化我

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

这项技能会协调另外三项技能：内联挖掘步骤（见步骤 1）、你的运行环境中的技能编写技能（编写），以及 unslop 技能（文风规范）。它负责安排执行顺序，不会取代它们。

技能编写技能是 Cursor 中的 create-skill（内置），或 Anthropic 的 skill-creator。如果两者都没有，请遵循 agentskills.io 上的 Agent Skills 格式。下文中的“create-skill”指你使用的其中一种。

流程

0. 检查是否已有技能

在运行环境的技能文件夹中递归查找与用户代号匹配的 *-mode/SKILL.md。项目中的位置：.cursor/skills/（Cursor）、.claude/skills/（Claude Code）、.pi/skills/（Pi）或 .agents/skills/（Codex、OpenCode 等）。用户目录中的位置：~/.cursor/skills/、~/.claude/skills/、~/.pi/agent/skills/、~/.codex/skills/、~/.config/opencode/skills/ 或 ~/.agents/skills/。Mode 技能可以存放在个人分类目录（<skills>/<handle>/）中，而不只是顶层目录。如果已存在，除非用户已经说过“更新我的技能”或类似的话，否则请使用结构化提问工具确认其意图（Cursor 中的 AskQuestion、Claude Code 中的 AskUserQuestion、OpenCode 中的 question）：

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

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

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

1. 挖掘用户的历史记录

启动并行处理前，先定位当前工作区的转录记录。只使用该工作区的目录。不要跨所有项目目录进行全局匹配，因为这会越过工作区边界，读取无关项目中的私人聊天记录。具体位置取决于运行环境：

• Cursor： 系统提示词会指出 ~/.cursor/projects/ 下该工作区的 agent-transcripts/ 目录。
• Claude Code： ~/.claude/projects/<slug>/*.jsonl，其中 <slug> 是工作区路径：将所有非字母或数字字符替换为“-”。
• Pi： ~/.pi/agent/sessions/--<slug>--/*.jsonl，其中 <slug> 是去掉前导斜杠、并将每个“/”替换为“-”后的工作区路径。
• Codex： ~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl。只保留首行中 payload.cwd 与工作区路径相同的文件。
• 其他运行环境： 该运行环境中属于此工作区的会话目录。

在限定范围内查看近期 Agent 对话，寻找反复出现的模式。并行启动多个子 Agent，分别处理不同的历史记录区段（例如最近 2–4 周，分为 3 个区段，让每个区段都有足够的材料）。根据 poteto-mode 技能的“子 Agent”部分，为任务选择每个子 Agent 的推理级别和快速或标准速度。每个负责挖掘某个区段的子 Agent 都应读取父 Agent 提供的工作区范围内路径，查找以下信号，并返回简短的结构化模式列表及证据指针。默认值得寻找的信号：

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

在不同区段之间交叉核对后，再确定是否将某项信号纳入技能。出现在 2 个或更多区段中的模式可信度较高。只出现一次的信号较弱，通常应舍弃。

2. 直接询问用户

挖掘无法发现尚未提及的意图。使用结构化提问工具（结构化多选题：Cursor 中的 AskQuestion、Claude Code 中的 AskUserQuestion、OpenCode 中的 question），而不是让用户从头开始输入。如果你的工具框架没有此类工具，就在聊天中提出带编号的选项。

形式：每轮提出一到两个问题，每题提供 4–6 个选项；对于类别问题，允许多选（Cursor 中设置 allow_multiple: true）。先问宽泛的问题（“哪些方面对你最重要？”），再针对用户选中的方面提供具体选项。完成结构化提问后，再通过一个开放式聊天问题了解选项未涵盖的内容。

不要一次性抛出 20 个问题。

3. 整理发现

将综合信号归纳到不同部分。常见类别如下（仅使用适用项）：

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

poteto-mode 技能展示了应有的形式。阅读它以了解详细程度，但不要照搬其内容。用户的规则与 poteto-mode 的规则并不相同。

4. 起草技能

使用技能编写技能（create-skill）来编写该技能。存放位置：

• 路径：保留现有模式技能的类别。对于新模式，如果仓库已为该用户代号设有固定类别，则使用 <skills>/<handle>/<handle>-mode/SKILL.md。否则，默认存放在项目的 <skills>/<handle>-mode/SKILL.md，或在用户偏好个人技能时存放到用户级技能文件夹。<skills> 指第 0 步中你的工具框架所用的技能文件夹。
• 代号：用户的名字或选定的标识符。
• 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，无需挖掘。
• 用户想要记录某个狭窄的工作流（例如“我如何撰写提交消息”）。这是常规技能，不是模式技能。