skillify

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Skillify

Skillify

Capture this session's repeatable process into a reusable SKILL.md skill file. Call at the end of the process you want to capture, optionally with a description.
将本次会话的可重复流程捕获为可复用的SKILL.md技能文件。在你想要捕获的流程末尾调用,可选择性附带描述。

Inputs

输入参数

  • $description
    : (Optional) Description of the process you want to capture as a skill.
  • $description
    : (可选)你想要捕获为技能的流程的描述。

Goal

目标

Create a well-structured, reusable SKILL.md file that captures a repeatable process from the current session so it can be invoked again later.
创建结构清晰、可复用的SKILL.md文件,捕获当前会话中的可重复流程,以便后续可以再次调用。

Steps

步骤

1. Analyze the Session

1. 分析会话

Before asking any questions, analyze the conversation to identify:
  • What repeatable process was performed
  • What the inputs/parameters were
  • The distinct steps (in order)
  • The success artifacts/criteria (e.g. not just "writing code," but "an open PR with CI fully passing") for each step
  • Where the user corrected or steered you
  • What tools and permissions were needed
  • What agents were used
  • What the goals and success artifacts were
Success criteria: You have a clear mental model of the process, its steps, inputs, outputs, and success criteria.
在提问前,先分析对话识别以下内容:
  • 执行了什么可重复流程
  • 输入/参数是什么
  • 不同的步骤(按顺序)
  • 每个步骤的成功产出物/标准(例如不只是「编写代码」,而是「CI全量通过的已打开PR」)
  • 用户纠正或引导你的节点
  • 需要用到什么工具和权限
  • 使用了哪些Agent
  • 目标和成功产出物是什么
成功标准:你对流程、其步骤、输入、输出和成功标准有清晰的认知模型。

2. Interview the User

2. 询问用户

Use
AskUserQuestion
for ALL questions. Never ask questions via plain text. For each round, iterate as much as needed until the user is happy. The user always has a freeform "Other" option to type edits or feedback -- do NOT add your own "Needs tweaking" option. Just offer the substantive choices.
所有问题都使用
AskUserQuestion
发起。绝对不要通过纯文本提问。每一轮按需迭代直到用户满意为止。用户始终有自由形式的「其他」选项可以输入修改意见或反馈——不要自己添加「需要调整」选项,只提供实质性选择即可。

Round 1: High-level confirmation

第一轮:高层级确认

  • Suggest a name and description for the skill based on your analysis. Ask the user to confirm or rename.
  • Suggest high-level goal(s) and specific success criteria for the skill.
  • 根据你的分析为技能建议一个名称和描述,请用户确认或重命名。
  • 建议技能的高层级目标和具体成功标准。

Round 2: More details

第二轮:补充细节

  • Present the high-level steps you identified as a numbered list. Tell the user you will dig into the detail in the next round.
  • If you think the skill will require arguments, suggest arguments based on what you observed. Make sure you understand what someone would need to provide.
  • If it's not clear, ask if this skill should run inline (in the current conversation) or forked (as a sub-agent with its own context). Forked is better for self-contained tasks that don't need mid-process user input; inline is better when the user wants to steer mid-process.
  • Ask where the skill should be saved. Suggest a default based on context. Options:
    • This repo (
      .claude/skills/<name>/SKILL.md
      ) -- for workflows specific to this project
    • Personal (
      ~/.claude/skills/<name>/SKILL.md
      ) -- follows you across all repos
  • 将你识别出的高层级步骤以编号列表形式展示,告知用户你会在下一轮深入挖掘细节。
  • 如果你认为该技能需要传入参数,根据你观察到的内容建议参数,确保你了解使用者需要提供什么信息。
  • 如果尚不明确,询问该技能应该inline(在当前会话中)运行还是forked(作为拥有独立上下文的子Agent)运行。Forked模式适合不需要流程中用户输入的独立任务;inline模式适合用户需要在流程中进行引导的场景。
  • 询问技能的保存位置,根据上下文给出默认建议。可选位置:
    • 本仓库 (
      .claude/skills/<name>/SKILL.md
      ) -- 适用于本项目专属的工作流
    • 个人 (
      ~/.claude/skills/<name>/SKILL.md
      ) -- 可在所有仓库中使用

Round 3: Breaking down each step

第三轮:拆解每个步骤

For each major step, if it's not glaringly obvious, ask:
  • What does this step produce that later steps need? (data, artifacts, IDs)
  • What proves that this step succeeded, and that we can move on?
  • Should the user be asked to confirm before proceeding? (especially for irreversible actions like merging, sending messages, or destructive operations)
  • Are any steps independent and could run in parallel? (e.g., posting to Slack and monitoring CI at the same time)
  • How should the skill be executed? (e.g. always use a Task agent to conduct code review, or invoke an agent team for a set of concurrent steps)
  • What are the hard constraints or hard preferences? Things that must or must not happen?
You may do multiple rounds of
AskUserQuestion
here, one round per step, especially if there are more than 3 steps or many clarification questions.
IMPORTANT: Pay special attention to places where the user corrected you during the session, to help inform your design.
针对每个主要步骤,如果不够清晰明确,询问以下问题:
  • 这个步骤会产生哪些后续步骤需要的内容?(数据、产出物、ID)
  • 什么可以证明该步骤成功,可以进入下一步?
  • 是否需要在执行前询问用户确认?(尤其是合并、发送消息、破坏性操作等不可逆动作)
  • 是否有步骤是独立的,可以并行运行?(例如同时发送Slack消息和监控CI运行状态)
  • 该技能应该如何执行?(例如始终使用Task Agent进行代码评审,或者调用Agent团队执行一组并发步骤)
  • 有什么硬性约束或偏好?必须做或者禁止做的事情有哪些?
你可以在这里进行多轮
AskUserQuestion
询问,每个步骤一轮,尤其是当步骤超过3个或者有很多需要澄清的问题时。
重要提示:特别注意会话过程中用户纠正你的节点,这对你的设计非常有参考价值。

Round 4: Final questions

第四轮:最终问题

  • Confirm when this skill should be invoked, and suggest/confirm trigger phrases too. (e.g. "Use when the user wants to cherry-pick a PR to a release branch. Examples: 'cherry-pick to release', 'CP this PR', 'hotfix'.")
  • Ask for any other gotchas or things to watch out for, if still unclear.
Stop interviewing once you have enough information. Don't over-ask for simple processes!
Success criteria: You have all the information needed to write the SKILL.md file and the user has confirmed the design.
  • 确认该技能应该在什么时候被调用,同时建议/确认触发短语。(例如:「当用户想要将PR cherry-pick到发布分支时使用。示例:'cherry-pick to release'、'CP this PR'、'hotfix'。」)
  • 如果仍不明确,询问是否有其他需要注意的问题或陷阱。
获取到足够信息后就停止询问,简单流程不要过度提问!
成功标准:你已获取编写SKILL.md文件所需的全部信息,且用户已确认设计方案。

3. Write the SKILL.md

3. 编写SKILL.md

Create the skill directory and file at the location the user chose in Round 2. Use this format:
markdown
---
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}}
---
在用户第二轮选择的位置创建技能目录和文件,使用以下格式:
markdown
---
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}}

{{Skill Title}}

Description of skill
Description of skill

Inputs

Inputs

  • $arg_name
    : Description of this input
  • $arg_name
    : Description of this input

Goal

Goal

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

Steps

Steps

1. Step Name

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.

**Per-step annotations** (include where relevant):
- **Success criteria** is REQUIRED on every step.
- **Execution**: `Direct` (default), `Task agent` (straightforward subagents), `Teammate` (agent with true parallelism and inter-agent communication), or `[human]` (user does it). Only needs specifying if not Direct.
- **Artifacts**: Data this step produces that later steps need (e.g., PR number, commit SHA). Only include if later steps depend on it.
- **Human checkpoint**: When to pause and ask the user before proceeding. Include for irreversible actions (merging, sending messages), error judgment (merge conflicts), or output review.
- **Rules**: Hard rules for the workflow. User corrections during the reference session can be especially useful here.

**Step structure tips:**
- Steps that can run concurrently use sub-numbers: 3a, 3b
- Steps requiring the user to act get `[human]` in the title
- Keep simple skills simple -- a 2-step skill doesn't need annotations on every step

**Frontmatter rules:**
- `allowed-tools`: Minimum permissions needed (use patterns like `Bash(gh:*)` not `Bash`)
- `context`: Only set `context: fork` for self-contained skills that don't need mid-process user input.
- `when_to_use` is CRITICAL -- tells the model when to auto-invoke. Start with "Use when..." and include trigger phrases.
- `arguments` and `argument-hint`: Only include if the skill takes parameters. Use `$name` in the body for substitution.

**Success criteria**: The complete SKILL.md content has been drafted.
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.

**每步注解**(相关场景下需要包含):
- **Success criteria** 是每个步骤的必填项,用于说明步骤已完成可以进入下一步,可以是列表形式。
- **Execution**:`Direct`(默认)、`Task agent`(简单子Agent)、`Teammate`(支持真正并行和Agent间通信的Agent)、或`[human]`(用户手动执行),非Direct模式才需要指定。
- **Artifacts**:该步骤产生的、后续步骤需要依赖的数据(例如PR编号、commit SHA),仅当后续步骤有依赖时需要包含。
- **Human checkpoint**:需要暂停并询问用户确认再继续的节点,不可逆动作(合并、发消息)、错误判断(合并冲突)或输出审核场景需要包含。
- **Rules**:工作流的硬性规则,参考会话过程中用户的纠正内容会非常有用。

**步骤结构提示**:
- 可以并行运行的步骤使用子编号:3a、3b
- 需要用户执行的步骤在标题中添加`[human]`
- 简单技能保持简洁——2步的技能不需要每个步骤都加注解

**前置元数据规则**:
- `allowed-tools`:需要的最小权限(使用类似`Bash(gh:*)`的模式,不要直接写`Bash`)
- `context`:仅当技能是不需要流程中用户输入的独立任务时,才设置`context: fork`
- `when_to_use` 是核心字段——告诉模型什么时候自动调用该技能,以「Use when...」开头,包含触发短语。
- `arguments` 和 `argument-hint`:仅当技能需要接收参数时包含,在正文中使用`$name`进行变量替换。

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

4. Review and Save

4. 审核与保存

Before writing the file, output the complete SKILL.md content as a yaml code block in your response so the user can review it with proper syntax highlighting. Then ask for confirmation using
AskUserQuestion
with a simple question like "Does this SKILL.md look good to save?"
After writing, tell the user:
  • Where the skill was saved
  • How to invoke it:
    /{{skill-name}} [arguments]
  • That they can edit the SKILL.md directly to refine it
Success criteria: The file is written to disk and the user has been informed how to use it.
写入文件前,将完整的SKILL.md内容作为yaml代码块输出到你的回复中,方便用户在正确的语法高亮下审核。然后使用
AskUserQuestion
发起确认,提问类似「这个SKILL.md可以保存吗?」的简单问题。
写入完成后,告知用户:
  • 技能的保存位置
  • 如何调用:
    /{{skill-name}} [arguments]
  • 用户可以直接编辑SKILL.md进行优化
成功标准:文件已写入磁盘,且用户已了解使用方法。