automate-me

自动化我

在 Codex 上，请先阅读平台映射，包括其中针对每项技能的说明，再执行这项技能。

在 GitHub Copilot 上，请先阅读平台映射，包括其中针对每项技能的说明，再执行这项技能。

在 Muse 上，请先阅读平台映射，包括其中针对每项技能的说明，再执行这项技能。

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

这项技能会协调另外三项技能：内联挖掘流程（见步骤 1）、plugin-dev:skill-development 技能（编写）和 unslop 技能（行文规范）。它负责安排流程，不会取代它们。

流程

0. 检查是否已有技能

递归查找与用户标识匹配的 .claude/skills/**/*-mode/SKILL.md 和 ${CLAUDE_CONFIG_DIR:-$HOME/.claude}/skills/*-mode/SKILL.md。Mode 技能可以放在个人分类目录（.claude/skills/<handle>/）中，不一定只在顶层目录。如果找到现有技能，请通过 AskUserQuestion 确认用户意图（除非用户已经说过“更新我的技能”或类似的话）：

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

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

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

1. 挖掘用户历史记录

并行分派任务前，先定位当前工作区的对话记录。Claude Code 将它们存储在 ${CLAUDE_CONFIG_DIR:-$HOME/.claude}/projects/<encoded-cwd>/*.jsonl 中。运行 node <plugin>/skills/reflect/scripts/claude-project-dir.mjs，打印本次会话对应的目录，不要手动拼出 <encoded-cwd>。只能使用该路径。不要对 ${CLAUDE_CONFIG_DIR:-$HOME/.claude}/projects/ 进行全局匹配，否则会跨越工作区边界，读取来自无关项目的私人对话。

在此范围内调查近期 Agent 对话，寻找反复出现的模式。并行运行多个子 Agent，分别分析历史记录的不同时间段（例如最近 2-4 周，分成 3 个时间段，确保每段都有足够材料）。根据 poteto-mode 技能的 Subagents 部分，为每个子 Agent 选择适合任务的推理级别。每个负责挖掘某个时间段的子 Agent 都应读取父 Agent 提供的工作区限定路径，查找以下信号，并返回一份简短的结构化模式清单及其证据指针。默认值得关注的信号包括：

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

在提升为确定信号前，先交叉核对不同时间段的结果。在 2 个或更多时间段中出现的模式属于高置信度信号。只出现一次的信号较弱，通常应舍弃。

2. 直接询问用户

挖掘无法发现尚未在对话中体现的意图。请使用 AskUserQuestion 工具（结构化多选），而不是让用户从头自由作答。

问题设计：提 1 到 2 个问题，每个问题提供 4-6 个选项；对类别类问题设置 allow_multiple: true。先从宽泛问题开始（“哪些方面最重要？”），再根据用户选中的方面追问具体选项。结构化提问结束后，再用一个自由回答问题了解选项未覆盖的内容。

不要一口气抛出 20 个问题。

3. 汇总发现

将综合信号归纳到各个部分。常见部分如下（仅使用适用的部分）：

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

poteto-mode 技能展示了合适的细致程度。阅读它以了解粒度，不要照搬其中的内容。用户的规则与 poteto-mode 的规则并不相同。

4. 起草技能

使用 plugin-dev:skill-development 技能编写该技能。存放位置：

• 路径：沿用现有模式技能的类别。对于新模式，如果仓库已为该标识符建立个人类别，请使用 .claude/skills/<handle>/<handle>-mode/SKILL.md。否则，默认放在项目中的 .claude/skills/<handle>-mode/SKILL.md（如果用户偏好个人技能，则放在 ${CLAUDE_CONFIG_DIR:-$HOME/.claude}/skills/<handle>-mode/）。
• 标识符：用户的名字或选定的标识符。
• Frontmatter description：应在提及用户名字、/<handle>-mode 和“按其风格工作”时触发，不要使用“编写代码”或“审查 PR”等通用关键词。
• Frontmatter 格式：遵循 plugin-dev:skill-development 的 YAML 规则。将 description 保持为单个 YAML 标量。如标点或换行有需要，可将其加引号，或使用 description: >- 并缩进后续行。
• Frontmatter 中默认设置 disable-model-invocation: true。只有用户明确希望其模式在每轮对话中都生效时，才取消此设置。

5. 迭代文案

对每一行应用 unslop 技能和 plugin-dev:skill-development 的写作指南。

向用户展示草稿并征求反馈。预期会有多轮迭代。果断删减。模式技能不是一本手册。

6. 提交

在基于 main 创建的 worktree 中工作。提交并创建 PR。不要直接推送到 main。

注意事项

• 不要过度拟合单次对话。 某项偏好只提过一次，且在其他时候又有相反表述，这属于噪声。多次出现后再将其写入技能。
• 不要卖弄。 重述其他技能的内容、编造比喻，或为 Agent 读者写“诗意”的文案，都是徒增成本。保持可操作性。
• 引用，不要内嵌。 用户依赖的其他技能应以路径形式引用，而不是粘贴其中的摘录。用户在其他位置维护的原则文档也一样。
• 保持章节精简。 只有当用户在该方面有具体的非默认规则时，才添加章节。“清晰沟通”不应单独成节。“段落简短。比较选项时使用表格。仅当条目确实相互并列时才使用项目符号。”则可以。
• 命名约定保持通用。 在指令中使用“用户”或“人类”，不要使用作者的名字。
• 不要强求对称。 如果用户没有值得记录的流程规则，就完全跳过“流程”部分。

评估

-mode 技能的输出具有主观性。plugin-dev:skill-development 风格的测试 / 迭代基准循环在此并不适用。请与用户一起进行直觉检验：读起来像用户的风格吗？有没有遗漏？然后即可发布。

只有当技能的触发准确度在实际使用中出现问题时，才运行描述优化循环。

何时不使用

• 用户想要的是针对特定任务的技能（而非工作约定）：只使用 plugin-dev:skill-development，无需挖掘偏好。
• 用户想记录某个狭窄的工作流（例如“如何写提交信息”）。这属于常规技能，而非模式技能。