automate-me

自动化我

以粗体或反引号标出的技能名称，或以 /<name> 形式运行的技能，都是本技能目录旁边的 ../<name>/SKILL.md 文件；未带前缀的原则名称对应 ../principle-<name>/SKILL.md。读取文件并遵循其中的要求。大多数 pstack 技能仅供用户使用，因此你的技能工具无法加载它们。每次 delegate_task 调用都遵循 ../poteto-mode/SKILL.md 中 Subagents 部分的默认设置。

这是一个引导式流程，用于将用户的工作约定转化为 Agent 会遵循的技能。输出是一个为用户量身定制的 -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，找出与用户句柄匹配的文件。解析后指向同一真实路径的条目视为同一技能。Mode 技能可以放在个人分类目录中（.agents/skills/<handle>/ 或 .claude/skills/<handle>/），不一定只在顶层目录。如果找到现有技能，请在对话中确认用户意图（除非用户已经说过“更新我的技能”或类似的话）：

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

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

• 步骤 1 只挖掘技能上次编辑之后的历史记录（git log -1 --format=%cI <path>）。
• 步骤 2 询问有哪些变化或遗漏，而不是从零开始询问要记录什么。
• 步骤 4 先确保技能的真实目录位于 .agents/skills/ 下，并创建对应的 .claude/skills/ 相对符号链接（如果技能原本只位于 .claude/skills/，则将其移入），然后原地编辑现有文件。保留用户未提出异议的章节；根据新证据修订相关章节。只有出现真正的新规则时，才添加新章节。

1. 挖掘用户的历史记录

在展开并行任务之前，先定位当前项目的对话。省略 projectId 时，t3_thread_list 和 t3_thread_search 会限定在调用线程所属的项目中。只使用该范围，不要传入其他 projectId，否则会跨项目边界读取无关项目中的私密聊天记录。

在该范围内调查近期 Agent 对话，寻找反复出现的模式。并行运行多个 delegate_task 子任务（mode: "async"，title 用于标明负责的片段，clientRequestId 在该片段的重试中保持稳定、每轮使用新的 ID，不设置 target，以便在父模型上运行），将历史记录分成多个片段（例如最近 2-4 周，分成 3 个片段，确保每个片段都有足够材料）。根据 poteto-mode 技能的 Subagents 部分，为每个子 Agent 选择适合任务的推理级别和快速或标准速度。子任务只能获取其任务说明，因此每个片段的说明都必须列出父任务找到的该片段的线程 ID，并注明“只读：仅检查，不写入，不运行 git 命令”和“不要委派任务”。每个片段的挖掘子任务都应使用 t3_thread_read 读取这些线程，寻找以下信号，并返回一份简短的结构化列表，列出发现的模式及其证据指针。默认值得寻找的信号包括：

• 回复偏好（长度、语气、格式、“说得简单点”之类的纠正）
• 委派习惯（子 Agent、模型、专用工作流、并行处理）
• 验证方式（如何判断“完成”、单元测试与实时复现、评审者）
• 代码与文案规范（风格、引用的原则、lint/格式化工具）
• 流程约定（worktree、提交、PR、评审/合并工具）
• 元偏好（任务进行中修改技能、提出创建新技能）

结束本轮并等待完成通知唤醒你。等所有片段都报告后，再跨片段交叉核对，然后才将信号提炼为规则。在 2 个或更多片段中出现的模式可信度较高。只出现一次的信号较弱，通常应舍弃。

2. 直接询问用户

挖掘无法发现尚未提及的意图。直接在对话线程中提问，并用结构化的多选题，而不是让用户从头开始输入。

形式：提出一到两个问题，每题提供 4-6 个选项；类别问题使用多选。先从宽泛的问题开始（“哪些方面对你最重要？”），然后根据用户选择的方面，追问具体选项。结构化提问结束后，再用一个开放式聊天问题收集选项未涵盖的内容。

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

3. 整理发现

将收集到的信号归入不同部分。常见类别如下（仅使用适用的类别）：

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

poteto-mode 技能展示了格式和详略程度。请阅读它，但不要照搬其内容。用户的规则与 poteto-mode 的规则并不相同。

4. 起草技能

如果已安装 skill-creator 技能，请用它编写技能；否则使用 Authoring-a-skill 操作手册（../poteto-mode/playbooks/authoring-a-skill.md）。放置位置：

• 路径：保留现有模式技能的类别。对于新模式，如果仓库中已有该用户专属的类别，则使用 .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 description：设置为在提及用户名字 + /<handle>-mode + “以他们的风格工作”时触发，不要使用“编写代码”或“审查 PR”之类的通用关键词。
• Frontmatter 格式：遵循 skill-creator 的 YAML 规则。将 description 保持为单个 YAML 标量。若标点或换行需要特殊处理，请用引号括起，或使用 description: >- 并缩进后续行。
• 默认添加 Frontmatter disable-model-invocation: true，并添加 agents/openai.yaml，其中包含 policy.allow_implicit_invocation: false，以便 Codex 也隐藏该技能。只有在用户明确希望该模式在每轮对话中都生效时，才同时取消这两项设置。

5. 反复打磨文案

对每一行都应用 unslop 技能和 skill-creator 的写作指南。

向用户展示草稿并征求反馈。预期需要多轮迭代。精简为要点。模式技能不是操作手册。

6. 完成并提交

在基于 main 创建的 worktree 中操作。提交更改，通过 gh pr create 创建 PR，并立即用 link_pull_request 关联其 URL。不要直接推送到 main。

约束

• 不要过拟合单次对话。 某项偏好只提过一次，且另一次又与之矛盾，这只是噪声。多次出现后再将其写成规则。
• 不要耍小聪明。 重述其他技能的内容、编造比喻，或为 Agent 读者写“诗意”的文字，都是徒劳无益。保持实用。
• 引用，不要内嵌。 用户依赖的其他技能应以路径引用的形式出现，而不是粘贴摘录。用户在其他地方维护的原则文档也一样。
• 精简章节。 只有当某个章节包含用户特有的、非默认规则时才添加。“清晰沟通”不算一个章节。“段落简短。比较选项时使用表格。只有条目确实并列时才使用项目符号。”才算。
• 命名约定通用化。 在指令中使用“用户”或“人类”，而不是作者的名字。
• 不要强求对称。 如果用户没有值得记录的流程规则，就完全跳过“流程”章节。

评估

-mode 技能的输出具有主观性。skill-creator 式的测试／迭代基准循环在这里没有用。请与用户一起进行直觉检查：读起来像他们吗？有没有遗漏什么？然后交付。

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

何时不使用

• 用户想要的是特定任务的技能（而非工作约定）：只使用 skill-creator，无需挖掘。
• 用户想要记录一个范围狭窄的工作流（例如“如何写提交消息”）。这是常规技能，不是模式技能。