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