skillify

Skillify

将本次会话中可重复的流程记录为可复用的技能。

会话上下文

你可以查看完整的对话历史。请直接分析历史记录，了解执行了什么流程、使用了哪些工具，以及用户如何引导你。

如果用户提供了描述：用户将此流程描述为： "$description"

你的任务

步骤 1：分析会话

在提问之前，请先分析对话历史，确定：

• 执行了什么可重复的流程
• 输入和参数是什么
• 各个步骤及其顺序
• 每个步骤的成功产物或标准（例如，不只是“编写代码”，而是“已创建一个 PR，且 CI 全部通过”）
• 用户在哪些地方纠正或引导了你
• 需要哪些工具和权限
• 使用了哪些 Agent
• 目标和成功产物是什么

第 2 步：采访用户

你将使用 AskUserQuestion 了解用户想要自动化的内容。 重要说明：

• 所有问题都要使用 AskUserQuestion！绝不要通过纯文本提问。
• 每一轮都要根据需要反复询问，直到用户满意。
• 用户始终可以通过自由填写的“其他”选项输入修改意见或反馈——不要自行添加“需要调整”或“我会提供修改意见”选项。只提供实质性选项。

第 1 轮：高层确认

• 根据你的分析，为技能建议一个名称和描述，并询问用户是否确认或要更改名称。
• 为技能建议高层目标和具体成功标准。

第 2 轮：更多详情

• 用编号列表展示你确定的高层步骤。告诉用户你将在下一轮深入讨论细节。
• 如果你认为技能需要参数，请根据观察提出建议，并确保弄清楚使用者需要提供什么。
• 如果尚不明确，询问该技能应该内联运行（在当前对话中），还是分叉运行（作为拥有独立上下文的子 Agent）。对于不需要用户在过程中输入的独立任务，分叉运行更合适；如果用户希望在过程中引导执行，则内联运行更合适。
• 询问技能应保存在哪里。根据上下文建议默认位置（特定于代码仓库的工作流 -> 代码仓库；跨代码仓库的个人工作流 -> 用户）。 选项：
  • 此代码仓库（.claude/skills/<name>/SKILL.md）——适用于特定于此项目的工作流
  • 个人（~/.claude/skills/<name>/SKILL.md）——可在所有代码仓库中使用

第 3 轮：拆解每个步骤 对于每个主要步骤，如果并非一目了然，请询问：

• 此步骤会产出什么供后续步骤使用？（数据、制品、ID）
• 什么能证明此步骤已成功，可以继续？
• 继续之前是否应该让用户确认？（尤其是合并、发送消息或破坏性操作等不可逆操作）
• 是否有步骤彼此独立，可以并行运行？（例如，同时在 Slack 发布内容并监控 CI）
• 技能应如何执行？（例如，始终使用 Task Agent 进行代码审查，或调用 Agent 团队并行执行一组步骤）
• 有哪些严格限制或明确偏好？哪些事情必须做或绝不能做？

你可以在此处进行多轮 AskUserQuestion，每个步骤一轮；尤其是在步骤超过 3 个或有许多问题需要澄清时。根据需要反复询问。

重要：特别留意用户在会话中纠正你的地方，并据此完善设计。

第 4 轮：最后的问题

• 确认何时应调用此技能，并建议或确认触发短语。（例如，对于 cherry-pick 工作流，可以说：在用户想将 PR cherry-pick 到发布分支时使用。示例：“cherry-pick 到发布分支”“把这个 PR CP 过去”“hotfix”。）
• 如果仍有不明确之处，也可以询问其他注意事项或需要留意的事项。

收集到足够信息后就停止采访。重要：对于简单流程，不要过度提问！

步骤 3：编写 SKILL.md

在用户于第 2 轮选择的位置创建技能目录和文件。

使用以下格式：

---
name: { { skill-name } }
description: { { one-line description } }
allowed-tools: { { list of tool permission patterns observed during session } }
when_to_use:
  {
    {
      detailed description of when Claude should automatically invoke this skill,
      including trigger phrases and example user messages,
    },
  }
argument-hint: "{{hint showing argument placeholders}}"
arguments: { { list of argument names } }
context: { { inline or fork -- omit for inline } }
---

# {{Skill Title}}

Description of skill

## Inputs

- `$arg_name`: Description of this input

## Goal

Clearly stated goal for this workflow. Best if you have clearly defined
artifacts or criteria for completion.

## Steps

### 1. Step Name

What to do in this step. Be specific and actionable. Include commands when
appropriate.

**Success criteria**: ALWAYS include this! This shows that the step is done and
we can move on. Can be a list.

IMPORTANT: see the next section below for the per-step annotations you can
optionally include for each step.

...

逐步注释：

• 成功标准：每个步骤都必须包含。它能帮助模型理解用户对工作流的期望，以及何时可以有把握地继续下一步。
• 执行方式：Direct（默认）、Task agent（简单的子 Agent）、Teammate（真正并行且可在 Agent 间通信的 Agent）或 [human]（由用户执行）。仅在非 Direct 时需要注明。
• 产物：此步骤生成且后续步骤需要的数据（例如 PR 编号、提交 SHA）。只有后续步骤依赖这些数据时才需包含。
• 人工检查点：何时暂停并在继续前询问用户。对于不可逆操作（合并、发送消息）、错误判断（合并冲突）或输出审阅，均需包含。
• 规则：工作流的硬性规则。用户在参考会话中提出的更正尤其有用。

步骤结构提示：

• 可并发执行的步骤使用子编号：3a、3b
• 需要用户操作的步骤在标题中标注 [human]
• 保持简单技能简洁——两步技能无需为每个步骤添加注释

Frontmatter 规则：

• allowed-tools：仅授予所需的最低权限（使用 Bash(gh:*) 这类模式，而不是 Bash）
• context：仅对不需要用户在流程中途输入的自包含技能设置 context: fork。
• when_to_use 至关重要——它会告知模型何时自动调用。以“Use when...”开头，并包含触发短语。示例：“Use when the user wants to cherry-pick a PR to a release branch. Examples: 'cherry-pick to release', 'CP this PR', 'hotfix'.”
• arguments 和 argument-hint：仅在技能接受参数时添加。在正文中使用 $name 进行替换。

步骤 4：确认并保存

根据官方文档检查技能。使用 skill-creator 技能对其进行评估。

写入文件之前，先在回复中以 yaml 代码块输出完整的 SKILL.md 内容，供用户检查并获得正确的语法高亮。然后使用 AskUserQuestion 征求确认，问题应简短，例如“这个 SKILL.md 看起来可以保存吗？”——不要使用 body 字段，问题要简洁。

写入后，告知用户：

• 技能保存的位置
• 如何调用：/{{skill-name}} [arguments]
• 用户可以直接编辑 SKILL.md 进行完善