用途
Automate-me 是一个引导式流程，用于将用户的工作惯例、偏好和协作风格转化为一个智能体能够遵循的 -mode 技能。输出是一个为特定用户量身定制的 -mode 技能（例如 jay-mode、priya-mode）。
该技能协调三个其他技能：内联挖掘（见步骤 1）、skill-creator 技能（负责编写）和 unslop 技能（负责行文纪律）。它负责排序调度，不替代它们。
主要能力与流程
0. 检查现有技能
递归查找 .agents/skills/**/*-mode/SKILL.md、.claude/skills/**/*-mode/SKILL.md、~/.agents/skills/*-mode/SKILL.md 和 ~/.claude/skills/*-mode/SKILL.md 中匹配用户 handle 的文件。解析到同一真实路径的条目视为同一个技能。Mode 技能可以放在个人分类目录（.agents/skills/<handle>/ 或 .claude/skills/<handle>/）中，不仅限于顶层。如果已存在，则在聊天中确认意图（除非用户已经说过“更新我的技能”之类的话）：更新现有技能（重复运行时的默认选项）/ 从头开始（罕见，执行前先询问原因）。
更新模式会改变后续流程：
- 步骤 1 仅挖掘自技能上次编辑以来的历史（
git log -1 --format=%cI <path>）。 - 步骤 2 询问有什么变化或缺失，而不是从零开始捕获。
- 步骤 4 首先确保技能的真实目录位于
.agents/skills/下，并有匹配的相对.claude/skills/符号链接（如果它只存在于.claude/skills/下，则移动到该位置），然后就地编辑现有文件。保留用户未反驳的章节。用新证据修订章节。仅为真正的新规则添加新章节。
1. 挖掘历史
在分发给多个工作者之前，先定位活动项目的会话记录：../rex-subagents/scripts/sessions list --days <n> --no-workers 列出此仓库的 Claude Code 和 Codex 对话（包括工作树）。通过绝对路径运行，并且仅使用该范围。不要传递 --all-projects，那会跨越工作区边界并读取不相关项目的私人聊天。
在该范围内调查最近的智能体会话，寻找重复出现的模式。运行多个并行工作者，每个子智能体使用 --read-only 生成一次，覆盖历史切片（例如最近 2-4 周，分成 3 个切片，使每个切片有足够材料）。根据 poteto-mode 技能的 Subagents 部分，为每个子智能体选择推理级别和快速或标准速度。每个切片挖掘工作者在其任务简报中获得该切片的对话 ID 和 sessions 脚本的绝对路径，并带有“Do not delegate”，用 sessions read <id> 读取它们，寻找以下信号，并返回一个简短的结构化列表，列出它看到的模式及证据指针。默认值得寻找的信号：
- 响应偏好（长度、语气、格式、“dumb it down”修正）
- 委托习惯（子智能体、模型、专用工作流、并行性）
- 验证姿态（“完成”意味着什么，单元测试 vs 实时复现，审查者）
- 代码和行文纪律（风格、引用的原则、lint/format 工具）
- 流程惯例（工作树、提交、PR、审查/合并工具）
- 元偏好（任务中途修复技能、提出新技能）
结束回合，让唤醒线路启动下一回合。一旦每个切片都报告，在提升信号之前跨切片交叉检查。在 2 个以上切片中看到的模式是高置信度的。孤立信号是弱的，通常会被丢弃。
2. 直接询问用户
挖掘会遗漏尚未出现的意图。在聊天中使用结构化多选问题（有 Claude Code 的问题工具时使用它）询问，而不是让用户从零开始输入。
形式：一到两个问题，每个有 4-6 个选项，类别问题多选。从宽泛开始（“哪些领域最重要？”），然后针对选定领域用具体选项跟进。在结构化轮次之后，一个自由形式的聊天问题捕捉选项遗漏的任何内容。不要倾倒 20 个问题。
3. 聚类发现
将合并的信号分组为章节。常见章节（仅使用适用的）：
- 响应风格：长度、语气、格式。
- 自主性：不问就做多少，MCP 工具使用。
- 先理解：在界定或调查变更时使用哪些技能。
- 子智能体：默认、并行性、模型到任务、专用工作流。
- 行文/代码纪律：原则、lint 工具、风格指南。
- 审查和验证：复现姿态、验证技能、实时测试工具。
- 流程：git 工作树、提交、PR、审查/合并工具。
- 技能：技能编写习惯、先修复技能、提出新技能。
poteto-mode 技能展示了形状。阅读它以了解粒度。不要复制其内容。用户的规则与 poteto-mode 的规则不同。
4. 起草技能
当安装了 skill-creator 技能时使用它来编写技能，否则使用 Authoring-a-skill 手册（../poteto-mode/playbooks/authoring-a-skill.md）。放置位置：
路径：保留现有 mode 技能的分类。对于新 mode，当仓库有为该 handle 建立的个人分类时，使用 .agents/skills/<handle>/<handle>-mode/SKILL.md。否则默认使用项目中的 .agents/skills/<handle>-mode/SKILL.md（或如果用户偏好个人技能，则使用 ~/.agents/skills/<handle>-mode/）。在那里创建真实目录，然后在 .claude/skills/ 下的匹配路径创建相对符号链接（.claude/skills/<handle>-mode -> ../../.agents/skills/<handle>-mode，~/ 下相同）。
Handle：用户的名字或选择的标识符。
Frontmatter 描述：触发于他们的名字 + /<handle>-mode + “以他们的风格工作”，而不是通用关键词如“写代码”或“审查 PR”。
Frontmatter 格式：遵循 skill-creator 的 YAML 规则。将 description 保持为一个 YAML 标量。当标点或换行需要时，引用它或使用 description: >- 与缩进续行。
Frontmatter disable-model-invocation：默认 true，加上 agents/openai.yaml 与 policy.allow_implicit_invocation: false 以便 Codex 也隐藏它。仅在用户明确希望其 mode 在每回合应用时，才选择退出两者。
5. 迭代行文
将 unslop 技能和 skill-creator 的写作指南应用于每一行。向用户展示草稿并获取反馈。预期多次迭代。无情删减。mode 技能不是手册。
6. 落地
在基于 main 的工作树中工作。提交并用 gh pr create 打开 PR。不要直接推送到 main。
适用场景
- 用户希望将个人工作风格、偏好和协作习惯固化为智能体可遵循的技能。
- 用户希望智能体按照自己的方式工作，而不是通用默认方式。
- 用户已有一些历史对话可供挖掘，或愿意通过问答明确偏好。
限制与注意事项
护栏
- 不要过拟合于一次对话。一次陈述又在另一次被反驳的偏好是噪音。在编纂之前要求多个实例。
- 不要自作聪明。重述其他技能的内容、发明隐喻或为智能体读者写“诗意”行文是只有成本没有收益。保持可操作。
- 引用，不要内联。用户依赖的其他技能应作为路径引用出现，而不是粘贴摘录。他们维护的任何原则文档同样如此。
- 保持章节最少。仅当用户在那里有特定的、非默认规则时才添加章节。“清晰沟通”不是章节。“短段落。比较选项时用表格。仅当项目真正平行时用项目符号。”才是。
- 名称约定通用。在祈使句中使用“用户”或“人类”，而不是作者的名字。
- 不要强制对称。如果用户没有值得写下的流程规则，完全跳过 Process 章节。
评估
-mode 技能是主观输出。skill-creator 风格的测试/迭代基准循环在这里没有用。与用户进行 vibes 检查：它读起来像他们吗？它遗漏了什么吗？然后发布。仅在技能触发准确性在实践中成为问题时才运行描述优化循环。
何时不使用
- 用户想要任务特定技能（而非工作惯例）：仅使用 skill-creator，无需挖掘。
- 用户想要捕获一个狭窄的工作流（例如“我如何写提交信息”）。那是常规技能，不是 mode 技能。
其他限制
- 挖掘范围仅限活动项目的会话记录，不得使用
--all-projects跨越工作区边界。 - 默认不同步推送 main，需通过 PR 落地。
- 技能默认禁用模型隐式调用（disable-model-invocation: true 与 policy.allow_implicit_invocation: false），除非用户明确要求每回合应用。
暂未提供
- 具体收费、价格信息暂未提供。
- 支持平台暂未提供。