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