skillify

Skillify

将本次会话中可重复的流程记录到可复用的 SKILL.md 技能文件中。可在想要记录的流程结束时调用，也可以选择提供描述。

输入

• $description：（可选）你想记录为技能的流程描述。

目标

创建结构清晰、可复用的 SKILL.md 文件，记录当前会话中可重复执行的流程，以便之后再次调用。

步骤

1. 分析会话

在提问前，先分析对话，确定：

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

成功标准：你对流程的步骤、输入、输出和成功标准有清晰的认识。

2. 采访用户

所有问题都必须使用 AskUserQuestion 提问。不得以纯文本形式提问。每轮可根据需要继续追问，直到用户满意。用户始终可以通过自由填写的“其他”选项输入修改或反馈——不要自行添加“需要调整”选项，只提供实质性选项。

第 1 轮：高层确认

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

第 2 轮：更多详情

• 将你确定的高层步骤按编号列出。告知用户下一轮将深入讨论细节。
• 如果你认为技能需要参数，请根据观察结果提出建议。确保了解使用者需要提供什么。
• 如果尚不明确，询问该技能应以内联方式运行（在当前对话中），还是以分支方式运行（作为拥有独立上下文的子 Agent）。对于无需中途征询用户的独立任务，分支方式更合适；如果用户希望在过程中进行引导，则以内联方式更合适。
• 询问技能应保存在哪里。根据上下文建议默认位置。选项：
  • 此仓库（.claude/skills/<name>/SKILL.md）——适用于此项目专属的工作流
  • 个人目录（~/.claude/skills/<name>/SKILL.md）——适用于所有仓库

第 3 轮：拆解各步骤

对于每个主要步骤，如果不显而易见，请询问：

• 该步骤会产出什么供后续步骤使用？（数据、产物、ID）
• 如何判断该步骤成功并可以继续？
• 继续之前是否应征求用户确认？（尤其是合并、发送消息或破坏性操作等不可逆操作）
• 是否有步骤相互独立，可以并行执行？（例如，同时在 Slack 发布消息并监控 CI）
• 技能应如何执行？（例如，始终使用 Task Agent 进行代码审查，或为一组并行步骤调用 Agent 团队）
• 有哪些硬性约束或偏好？哪些事情必须做或绝不能做？

你可以进行多轮 AskUserQuestion，每个步骤进行一轮，特别是步骤超过 3 个或需要澄清的问题较多时。

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

第 4 轮：最终问题

• 确认何时应调用该技能，并建议或确认触发语句。（例如：“用户想将 PR 移植到发布分支时使用。示例：‘移植到发布分支’、‘把这个 PR CP 过去’、‘热修复’。”）
• 如果还有不明确之处，询问其他注意事项或需要留意的问题。

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

成功标准：已收集编写 SKILL.md 文件所需的全部信息，且用户已确认设计。

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.

逐步注释（在适用时添加）：

• 成功标准：每个步骤都必须包含。
• 执行方式：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..." 开头，并包含触发短语。
• 仅当技能接受参数时，才添加 arguments 和 argument-hint。在正文中使用 $name 进行替换。

成功标准：完整的 SKILL.md 内容已起草完成。

4. 审查并保存

写入文件前，在回复中以 yaml 代码块输出完整的 SKILL.md 内容，方便用户通过语法高亮进行审查。然后使用 AskUserQuestion 提出一个简单的问题，例如“这个 SKILL.md 看起来可以保存吗？”

写入后，告知用户：

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

成功标准：文件已写入磁盘，并已告知用户如何使用。