bench-new-skill

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/bench-new-skill — Create New Skills

/bench-new-skill — 创建新技能

Scaffold new skills for the bench-skills repo following established conventions and best practices.
按照既定约定和最佳实践,为bench-skills仓库搭建新技能的基础框架。

When to Use

使用场景

  • User wants to add a new skill to bench-skills
  • User says "create a new skill", "add a skill", "new slash command"
  • 用户想要为bench-skills添加新技能
  • 用户说“创建新技能”、“添加技能”、“新斜杠命令”

Principles

原则

  1. Description = triggering conditions. The description field tells Claude WHEN to use the skill, not WHAT it does. Focus on user phrases and situations that should trigger it.
  2. Start with concrete examples. Ask "What would you say to trigger this skill?" before designing anything.
  3. Include only what Claude doesn't already know. Don't teach Claude how to write code — teach it your specific process, conventions, and standards.
  4. Self-contained skills. Each skill directory must work independently when installed via
    npx skills add
    .
  5. Inline agent prompts. Keep agent prompts to 5-15 lines inline in SKILL.md. Only use
    references/
    for large templates or catalogs.
  6. Under 300 lines. If SKILL.md exceeds 300 lines, move large content to
    references/
    .
  1. 描述 = 触发条件。描述字段用于告知Claude何时使用该技能,而非技能的功能。重点关注应该触发技能的用户用语和场景。
  2. 从具体示例入手。在进行任何设计前,先问“你会说什么来触发这个技能?”
  3. 仅包含Claude未知的内容。无需教Claude如何编写代码——只需教它你的特定流程、约定和标准。
  4. 独立封装的技能。每个技能目录通过
    npx skills add
    安装后必须能独立运行。
  5. 内联Agent提示词。将Agent提示词控制在5-15行内,直接嵌入SKILL.md中。仅在处理大型模板或目录时使用
    references/
    文件夹。
  6. 控制在300行以内。如果SKILL.md超过300行,将大段内容移至
    references/
    文件夹。

Process

流程

Step 1: Understand the Skill

步骤1:理解技能需求

Ask the user:
AskUserQuestion:
  question: "What should this skill do? Give me 2-3 examples of what you'd say to trigger it."
From their response, identify:
  • Trigger phrases — What the user would say to invoke this
  • Core process — What steps the skill should follow
  • Output — What the skill produces
  • Agents needed — Does it need parallel subagents? For what?
询问用户:
AskUserQuestion:
  question: "这个技能应该实现什么功能?请给出2-3个你会用来触发它的示例表述。"
从用户的回复中明确:
  • 触发用语 — 用户会用什么表述来调用该技能
  • 核心流程 — 技能应遵循的步骤
  • 输出结果 — 技能生成的内容
  • 所需Agent — 是否需要并行子Agent?用于完成什么任务?

Step 2: Name the Skill

步骤2:为技能命名

Follow the
{area}-{name}
convention:
AreaFor
engineer-
Engineering workflow (plan, build, review)
product-
Product management (specs, requirements)
security-
Security auditing and best practices
knowledge-
Documentation and learning capture
bench-
Meta skills for bench-skills itself
Suggest a name and confirm with the user.
遵循
{领域}-{名称}
的命名约定:
领域适用场景
engineer-
工程工作流(规划、构建、评审)
product-
产品管理(需求文档、规格说明)
security-
安全审计与最佳实践
knowledge-
文档编写与知识留存
bench-
bench-skills自身的元技能
建议一个名称并与用户确认。

Step 3: Write the Description

步骤3:编写描述

The description field is the most important part — it determines when Claude activates the skill.
Good descriptions (focus on triggers):
Use when the user says "review this", "code review", or provides a PR number.
Bad descriptions (focus on capabilities):
A comprehensive code review tool that analyzes security, performance, and architecture.
描述字段是最重要的部分——它决定了Claude何时激活该技能。
优质描述示例(聚焦触发条件):
当用户说“评审这个”、“代码评审”,或者提供PR编号时使用。
不佳描述示例(聚焦功能):
一款全面的代码评审工具,可分析安全性、性能和架构。

Step 4: Scaffold the Skill

步骤4:搭建技能基础框架

Create the skill directory in the bench-skills repo:
~/bench-skills/skills/{skill-name}/
├── SKILL.md
└── references/          (only if needed for large templates/catalogs)
    └── {reference}.md
Write SKILL.md with this structure:
markdown
---
name: {skill-name}
description: {triggering conditions}
allowed-tools: [{tools needed}]
---
在bench-skills仓库中创建技能目录:
~/bench-skills/skills/{skill-name}/
├── SKILL.md
└── references/         (仅在需要大型模板或目录时使用)
    └── {reference}.md
按照以下结构编写SKILL.md:
markdown
---
name: {skill-name}
description: {触发条件}
allowed-tools: [{所需工具}]
---

/{skill-name} — {Short Title}

/{skill-name} — {简短标题}

{One sentence explaining what this skill does.}
{一句话说明该技能的功能。}

When to Use

使用场景

  • {Trigger condition 1}
  • {Trigger condition 2}
  • {Trigger condition 3}
  • {触发条件1}
  • {触发条件2}
  • {触发条件3}

Process

流程

Step 1: {First Step}

步骤1:{第一步}

{Instructions}
{说明}

Step 2: {Second Step}

步骤2:{第二步}

{Instructions}
...
{说明}
...

Output

输出结果

{What the skill produces and where it's saved.}
{技能生成的内容及其保存位置。}

Next Steps

后续步骤

{What to do after running this skill. Link to other skills.}
undefined
{运行该技能后的操作建议。关联其他技能。}
undefined

Step 5: Validate

步骤5:验证

Check the skill against conventions:
  • Name follows
    {area}-{name}
    pattern
  • Description focuses on triggering conditions
  • SKILL.md under 300 lines
  • Self-contained (no dependencies on shared files)
  • Agent prompts are inline (5-15 lines each)
  • Steps are numbered and actionable
  • Links to other bench-skills where appropriate
  • allowed-tools
    includes only tools actually used
按照约定检查技能:
  • 名称遵循
    {领域}-{名称}
    格式
  • 描述聚焦触发条件
  • SKILL.md不超过300行
  • 独立封装(无对共享文件的依赖)
  • Agent提示词内联(每个5-15行)
  • 步骤编号清晰且可执行
  • 适当关联其他bench-skills技能
  • allowed-tools
    仅包含实际使用的工具

Step 6: Install

步骤6:安装

Tell the user to install the new skill:
bash
npx skills add ~/bench-skills -g -s {skill-name}
Or if using symlink mode and the repo is already installed, it's automatically available.
告知用户安装新技能:
bash
npx skills add ~/bench-skills -g -s {skill-name}
如果使用符号链接模式且仓库已安装,新技能会自动可用。

Skill Design Checklist

技能设计检查清单

Before finalizing, verify:
  1. Would this be triggered naturally? If the description requires users to know specific phrases, it's too narrow.
  2. Is this distinct from existing skills? Check that it doesn't overlap with: engineer-plan, engineer-work, engineer-review, product-brainstorm, product-prd, product-tech-spec, product-naming, security-audit, security-supabase, knowledge-compound.
  3. Is this teaching Claude something new? If Claude already knows how to do this without special instructions, the skill may not be needed.
  4. Is this the right granularity? A skill should be a complete workflow, not a single step. But it shouldn't try to do everything either.
最终确定前,验证以下内容:
  1. **是否能被自然触发?**如果描述要求用户知晓特定用语,范围则过于狭窄。
  2. **是否与现有技能区分开?**检查是否与以下技能重叠:engineer-plan、engineer-work、engineer-review、product-brainstorm、product-prd、product-tech-spec、product-naming、security-audit、security-supabase、knowledge-compound。
  3. **是否为Claude带来新内容?**如果无需特殊说明Claude就已知道如何完成该任务,则可能不需要此技能。
  4. **粒度是否合适?**一个技能应是完整的工作流,而非单一步骤,但也不应试图涵盖所有内容。