mcpField
M
make-skill

make-skill

github.com/tushaarmehtaaAgent 工作流1247 次安装2 周前更新
代码仓库

关于 make-skill

将可重复的工作流整理为便携式 Agent Skill，并生成可由编码 Agent 发现和加载的自包含目录。适合需要把流程转化为可复用技能的人，涵盖编写、验证与打包。

主要功能

  1. 01采集工作流需求
  2. 02编写技能 frontmatter 与正文
  3. 03按规范组织技能目录
  4. 04编写触发测试提示
  5. 05验证并打包技能

适用场景

  1. 01将团队流程封装为 Agent Skill
  2. 02为重复任务创建可复用技能
  3. 03检查技能结构和触发描述

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/tushaarmehtaa/tushar-skills --skill make-skill

安装后在 Claude Code 中输入/make-skill确认已加载。

附带文件references/guide.md

详细介绍

将任何可重复的工作流打包为可移植的 Agent Skill。输出是一个独立完整的技能目录，编码 Agent 可从 SKILL.md 中发现并加载它。

Phase 1：记录工作流

缺少信息时请提问：

  1. 它能做什么？——用一句话说明。它解决什么问题？
  2. 何时触发？——具体的短语或上下文。请说明确切。
  3. 它需要用户提供什么？——运行前所需的输入。
  4. 它会输出什么？——文件变更、代码、聊天内容、命令？
  5. 有哪些步骤？——从头到尾说明整个流程。
  6. 有哪些硬性规则？——必须始终遵守或绝不允许做的事。

如果当前对话已经描述了某个工作流，请先从中提取答案，再提问。不要询问已有的信息。

Phase 2：编写 Frontmatter

---
name: skill-name           # lowercase, hyphenated, no spaces
description: [What it does]. Use when [specific contexts or requests].
license: MIT
---

**description 是触发条件。**Agent 运行时会根据它决定何时激活技能。请明确说明，并将长度控制在 200 个字符以内，以确保广泛兼容：

  • 包含技能的用途以及使用时机
  • 指明具体的上下文或请求类型
  • 优先使用直接的 Use when ... 子句
  • 除非工作流确实依赖某个运行时，否则不要加入特定运行时的要求

仅使用 Agent Skills 规范中定义的字段。仅当技能存在实际的环境或运行时限制时，才添加 compatibility。不要在软件包 frontmatter 中放入仅供目录使用的字段，例如 category、tags 或 author。

Phase 3：编写正文

符合现有技能质量标准的结构：

[One-liner opener — what this does, what it outputs. No heading above this.]

## Phase 1: [First Phase Title]

[Instructions. Dense. Opinionated. No hedging.]

## Phase 2: [Next Phase Title]

...

## Verify

```text
[ ] [Thing that must be true]
[ ] [Thing that must be true]
[ ] [Edge case handled]
```

不可更改的规则：

  • 以一个完整句子开头——前面不要加 # Heading。这是 Agent 读取的第一条指令。
  • 每个主要章节都使用 ## Phase N: Title
  • 仅当 Phase 1 需要分支处理（技术栈检测、模式选择）时，才使用 ### 1.1 子阶段
  • 代码块必须包含真实、可运行的代码，而不是伪代码
  • 对可能静默失败或破坏整个流程的事项，在行内加粗警告
  • 以 ## Verify 结尾，并在代码块中使用裸 [ ] 项（不要使用 Markdown - [ ] 列表项）
  • 总行数少于 500 行——较长的示例请移至 references/guide.md

Phase 4：Verify 章节

Verify 章节不可省略。它用于确认技能是否正确运行。

格式必须严格如下——在围栏代码块中使用裸方括号：

## Verify

```
[ ] [Thing that must be true after the skill runs]
[ ] [Output format is correct]
[ ] [Edge case handled]
[ ] [Common mistake avoided]
```

每一项都必须可检查——要么已完成，要么未完成。不要使用“质量看起来不错”之类的模糊描述。

Phase 5：参考资料（如有需要）

出现以下情况时，请创建 references/guide.md：

  • 完整示例会使 SKILL.md 超过 500 行
  • 多个变体需要各自独立的章节
  • 边缘情况过于复杂，需要实际示例说明

参考文件必须包含真实的输入 → 输出示例，不能只是示例提纲。

Phase 6：测试提示词

编写 3–5 条应触发技能的提示词，以及 2 条不应触发技能的提示词：

"make a skill for PR reviews"          ✅ should trigger
"create a skill to audit my code"      ✅ should trigger
"turn this process into a skill"       ✅ should trigger
"review my PR"                         ❌ should not trigger (different skill)
"what skills are available?"           ❌ should not trigger

发布前使用这些提示词验证 description。如果某个应该触发的请求未能触发，请将相应短语添加到 description 中。

Phase 7：打包和验证

创建一个名称与技能完全一致的目录。将 SKILL.md 放在目录根目录，并将可选资源放入 references/、scripts/ 或 assets/。

交付前：

  1. 解析 YAML frontmatter，并确认名称与目录一致。
  2. 确认 description 说明了技能的用途和使用时机，且长度不超过 200 个字符。
  3. 检查每个相对 Markdown 链接是否都指向技能目录内的有效路径。
  4. 确认每个打包的参考文件都由 SKILL.md 直接链接，并说明何时阅读。
  5. 如果仓库中存在技能验证器，请运行它。
  6. 交付完整目录，而不只是 SKILL.md，以便安装时保留打包的资源。

Verify

[ ] YAML frontmatter uses standard fields only and includes name, description, and license
[ ] Name matches the lowercase hyphenated directory name
[ ] Description states what the skill does and when to use it in 200 characters or fewer
[ ] Body opens with a one-liner — no heading before it
[ ] All sections use ## Phase N: Title format
[ ] Code blocks contain real code, not pseudocode
[ ] Critical constraints are bolded inline
[ ] Verify section uses bare [ ] items in a fenced code block
[ ] SKILL.md is under 500 lines
[ ] Long examples moved to references/guide.md when needed and linked from SKILL.md
[ ] Every relative link resolves and every bundled reference is reachable
[ ] 3-5 test prompts written to validate triggers

请参阅 references/guide.md，了解带注释的可移植技能、多文件示例以及常见的结构错误。

评论

支持 Markdown