sales-request-skill

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Request or Build a Missing Sales Skill

请求或构建缺失的销售Skill

The user needs a sales, marketing, or GTM capability that doesn't have a skill yet. Help them contribute it or request it.

This skill always ends with a concrete action on GitHub:

Path A (Build): Create the skill files, commit, push, and open a pull request to
```
sales-skills/sales
```
Path B (Request): File a GitHub issue on
```
sales-skills/sales
```
describing what's needed

Do not stop at "here's what the PR/issue would look like" — actually create it using

gh pr create

gh issue create

用户需要一项尚未对应Skill的销售、营销或GTM能力。帮助他们贡献该Skill或请求创建该Skill。

本Skill始终以GitHub上的具体操作收尾：

路径A（构建）：创建Skill文件，提交、推送代码，并向
```
sales-skills/sales
```
仓库发起pull request
路径B（请求）：在
```
sales-skills/sales
```
仓库提交GitHub issue，描述所需的Skill

不要停留在“PR/Issue应该是什么样的”阶段——要使用

gh pr create

或

gh issue create

实际创建它们。

Step 1: Confirm the gap

步骤1：确认需求缺口

$ARGUMENTS

is provided, use it. Otherwise ask: "What sales, marketing, or GTM capability do you need that isn't covered by an existing skill?"

Verify the request fits the sales/marketing/GTM domain. If it's outside scope entirely (e.g., "build a database migration tool"), say so and suggest appropriate tools instead.

Check the existing skills by reviewing the routing table in

skills/sales-do/SKILL.md

and listing installed skills in

~/.claude/skills/

to make sure there isn't already a skill that covers this. If there's a close match, suggest it instead.

Summarize back to the user:

What they need: one sentence
Closest existing skill: what's close but doesn't quite fit
Category: which section it would belong in (Prospecting & Pipeline, Active Deals, Strategy & Content, Marketing & GTM, Research & Data, Creative & Design, etc.)

如果提供了

$ARGUMENTS

，则使用该参数。否则询问：“您需要哪些现有Skill未覆盖的销售、营销或GTM能力？”

验证请求是否属于销售/营销/GTM领域。如果完全超出范围（例如“构建数据库迁移工具”），请告知用户并推荐合适的工具。

通过查看

skills/sales-do/SKILL.md

中的路由表，以及

~/.claude/skills/

中已安装的Skill，确认现有Skill中没有覆盖该需求的。如果有相近的Skill，请推荐给用户。

向用户总结以下内容：

用户需求：一句话概括
最相近的现有Skill：相近但不完全匹配的Skill
分类：该Skill所属的板块（潜在客户开发与销售漏斗、活跃交易、策略与内容、营销与GTM、研究与数据、创意与设计等）

Step 2: Choose a path

步骤2：选择路径

Ask the user:

Would you like to:

Build the skill — I'll help you create it with proper structure and prepare a PR

Request the skill — I'll file a GitHub issue so the maintainers know it's needed

询问用户：

您希望：

构建该Skill —— 我将帮助您按照规范结构创建Skill并准备PR

请求该Skill —— 我将在GitHub提交Issue，让维护者了解该需求

Path A: Build the skill

路径A：构建Skill

Use skill-creator if available

若skill-creator可用

Check whether the

/skill-creator

skill is available. If available, delegate to it for the full create-test-iterate workflow.

When delegating to

/skill-creator

, provide this sales-specific context:

Repo conventions for this skill:
Naming:
sales-<problem>
for sales skills, descriptive names for marketing/GTM skills (e.g.,
cold-email
,
launch-strategy
)
Descriptions should use phrases salespeople and marketers actually say — "write a cold email", "prep for a discovery call", "handle this objection"
Description must end with negative triggers:
Do NOT use for X (use /alternative)
SKILL.md is the only required file — keep it focused and actionable

Skills should ask clarifying questions before acting (audience, stage, constraints)
Skills route through
/sales-do
— the description field determines when the router matches
Skill structure:
skills/<skill-name>/
├── SKILL.md        # Main instructions (required)
├── scripts/        # Deterministic operations (data fetching, validation, formatting)
├── references/     # Large reference material (>500 words — API docs, data models)
├── assets/         # Templates, examples, configuration files
└── evals/
    └── evals.json  # Test cases (optional, generated by skill-creator or manually)
SKILL.md body pattern (follow what other skills in this repo do):

Step to gather context (ask 2-4 questions about the user's specific situation)

Implementation steps with actionable output

Templates or frameworks relevant to the problem domain

Gotchas section with 3-5 common Claude failure points for this domain

Output formatting guidance

Next steps pointing to related skills

Key principles:
Don't state the obvious: Focus on info Claude wouldn't know — internal conventions, domain gotchas, non-obvious patterns

Avoid railroading: Use "typically" instead of "always". Give Claude flexibility to adapt to the situation.
Scripts: If the skill involves deterministic operations (data fetching, formatting, validation), include scripts in
scripts/
Progressive disclosure: Move reference material >500 words to
references/
directory

Then let skill-creator run its workflow.

检查

/skill-creator

Skill是否可用。如果可用，将完整的创建-测试-迭代工作流委托给它。

委托给

/skill-creator

时，需提供以下销售领域特定上下文：

本仓库的Skill规范：
命名：销售类Skill使用
sales-<问题>
格式，营销/GTM类Skill使用描述性名称（例如
cold-email
、
launch-strategy
）
描述应使用销售和营销人员实际会说的表述——“撰写开发信”、“准备发现性通话”、“处理异议”
描述必须包含负面触发条件：
Do NOT use for X (use /alternative)
仅需必备文件SKILL.md——内容需聚焦且可执行

Skill应先提出澄清问题再执行操作（受众、阶段、约束条件）
Skill通过
/sales-do
路由——描述字段决定路由是否匹配
Skill结构：
skills/<skill-name>/
├── SKILL.md        # 主说明文档（必填）
├── scripts/        # 确定性操作（数据获取、验证、格式化）
├── references/     # 大型参考资料（超过500字——API文档、数据模型）
├── assets/         # 模板、示例、配置文件
└── evals/
    └── evals.json  # 测试用例（可选，由skill-creator生成或手动创建）
SKILL.md正文模板（参考仓库中其他Skill的格式）：

收集上下文的步骤（询问2-4个关于用户具体场景的问题）

可执行的实现步骤

与问题领域相关的模板或框架

注意事项部分：列出3-5个该领域中Claude常见的失误点

输出格式指导

指向相关Skill的下一步建议

核心原则：
不陈述显而易见的内容：聚焦Claude不知道的信息——内部规范、领域注意事项、非通用模式

避免强制流程：使用“通常”而非“必须”，给Claude适应场景的灵活性
脚本：如果Skill涉及确定性操作（数据获取、格式化、验证），将其放在
scripts/
目录中
渐进式披露：超过500字的参考资料移至
references/
目录

随后让skill-creator执行其工作流。

If skill-creator is NOT available

若skill-creator不可用

Build the skill manually following the conventions above.

按照上述规范手动构建Skill。

Write the SKILL.md

编写SKILL.md

yaml

---
name: <skill-name>
description: "<What problem it solves>. Use when <trigger phrases the user would say>. Do NOT use for <X> (use /alternative)."
argument-hint: "[brief hint about expected arguments]"
license: MIT
metadata:
  author: sales-skills
  version: 1.0.0
---

Read 2-3 existing skills in

skills/

to match the tone and structure. Key things to get right:

Description field — This is how the

/sales-do

router and Claude decide whether to use the skill. Be specific about trigger phrases. Include both what the skill does AND when to use it:

yaml

undefined

yaml

---
name: <skill-name>
description: "<解决的问题>。当<用户会说的触发短语>时使用。Do NOT use for <X> (use /alternative)."
argument-hint: "[对预期参数的简要提示]"
license: MIT
metadata:
  author: sales-skills
  version: 1.0.0
---

阅读

skills/

目录中2-3个现有Skill，匹配其语气和结构。需重点注意以下内容：

描述字段——这是

/sales-do

路由和Claude决定是否使用该Skill的依据。需明确触发短语，同时包含Skill功能和使用场景：

yaml

undefined

Bad: too vague

反面示例：过于模糊

description: "Help with sales emails"

description: "帮助撰写销售邮件"

Good: specific triggers, covers edge cases

正面示例：明确触发短语，涵盖边缘场景

description: "Write and optimize cold outbound email sequences. Use when writing first-touch cold emails, building multi-step outreach sequences, A/B testing subject lines, or improving reply rates on existing campaigns."


**Body** — Should follow the question-first pattern: gather context about the user's situation before producing output. Include templates, frameworks, or examples that make the output immediately useful.

description: "撰写和优化开发信外发序列。当撰写首次触达开发信、构建多步骤触达序列、A/B测试邮件主题或提升现有活动的回复率时使用。"


**正文**——应遵循先提问的模式：在生成输出前收集用户场景的上下文。包含能让输出立即生效的模板、框架或示例。

Test the skill

测试Skill

Generate an

evals/evals.json

file inside the new skill directory with 2-3 realistic test cases. Each eval should represent a prompt a salesperson or marketer would actually say, with assertions describing what a good response looks like.

json

{
  "skill_name": "<skill-name>",
  "evals": [
    {
      "id": 0,
      "prompt": "realistic user prompt a salesperson or marketer would say",
      "expected_output": "description of what a successful response looks like",
      "assertions": [
        {"name": "assertion_name", "description": "specific thing to check in the output"}
      ]
    }
  ]
}

Run the eval prompts with the skill active and verify the outputs pass the assertions. This matches the schema that

/skill-creator

uses, so evals work the same regardless of which build path created the skill.

在新Skill目录中生成

evals/evals.json

文件，包含2-3个真实的测试用例。每个测试用例应代表销售或营销人员实际会提出的请求，并包含描述合格输出的断言。

json

{
  "skill_name": "<skill-name>",
  "evals": [
    {
      "id": 0,
      "prompt": "销售或营销人员会说的真实请求",
      "expected_output": "合格输出的描述",
      "assertions": [
        {"name": "断言名称", "description": "输出中需要检查的具体内容"}
      ]
    }
  ]
}

启用该Skill后运行测试用例，验证输出是否符合断言要求。该格式与

/skill-creator

使用的 schema 一致，无论通过哪种构建路径创建Skill，测试用例的工作方式都相同。

Submit the PR

提交PR

After creating the skill files, submit a pull request. Do all of these steps — don't stop at "here's what to do":

Update
```
skills/sales-do/SKILL.md
```
— add a row to the appropriate routing table
Update
```
README.md
```
— add a row to the appropriate catalog table
Create a branch:
```
git checkout -b add-<skill-name>
```

Stage and commit:

git add skills/<skill-name>/ evals/ skills/sales-do/SKILL.md README.md && git commit -m "Add <skill-name> skill"

Push:
```
git push -u origin add-<skill-name>
```
Open the PR:

bash

gh pr create \
  --repo sales-skills/sales \
  --title "Add <skill-name> skill" \
  --body "$(cat <<'EOF'

创建Skill文件后，提交pull request。需完成以下所有步骤——不要停留在“操作指南”阶段：

更新
```
skills/sales-do/SKILL.md
```
——在对应路由表中添加一行
更新
```
README.md
```
——在对应目录表中添加一行
创建分支：
```
git checkout -b add-<skill-name>
```

暂存并提交：

git add skills/<skill-name>/ evals/ skills/sales-do/SKILL.md README.md && git commit -m "Add <skill-name> skill"

推送分支：
```
git push -u origin add-<skill-name>
```
发起PR：

bash

gh pr create \
  --repo sales-skills/sales \
  --title "Add <skill-name> skill" \
  --body "$(cat <<'EOF'

Summary

摘要

Problem: <what the user is solving>
Category: <which section it belongs in>
Example invocation:
```
/<skill-name> <example prompt>
```

问题：<用户要解决的问题>
分类：<所属板块>
调用示例：
```
/<skill-name> <示例请求>
```

Files

文件

```
skills/<skill-name>/SKILL.md
```
— main instructions
```
skills/sales-do/SKILL.md
```
— routing table updated
```
README.md
```
— catalog table updated EOF )"


Return the PR URL to the user when done.

```
skills/<skill-name>/SKILL.md
```
—— 主说明文档
```
skills/sales-do/SKILL.md
```
—— 已更新路由表
```
README.md
```
—— 已更新目录表 EOF )"


完成后将PR链接返回给用户。

Path B: Request the skill

路径B：请求Skill

File a GitHub issue on the repo. Do not just draft it — actually submit it:

bash

gh issue create \
  --repo sales-skills/sales \
  --title "Skill request: <skill-name>" \
  --body "$(cat <<'EOF'

在仓库提交GitHub issue。不要仅编写草稿——需实际提交：

bash

gh issue create \
  --repo sales-skills/sales \
  --title "Skill request: <skill-name>" \
  --body "$(cat <<'EOF'

Problem

问题

<用户的需求，用他们的原话描述>

分类

<所属板块：潜在客户开发、活跃交易、策略、营销、研究、创意等>

Example use case

示例使用场景

<该Skill能发挥作用的具体场景>

Suggested trigger phrases

建议触发短语

<2-3 phrases a salesperson or marketer might say that should route to this skill> EOF )"


Return the issue URL to the user when done.

<2-3个销售或营销人员可能会说的、应路由到该Skill的短语> EOF )"


完成后将Issue链接返回给用户。

Quality checklist

质量检查清单

Before submitting a new skill (via PR or skill-creator), verify:

Name follows repo conventions (
```
sales-<problem>
```
for sales, descriptive for marketing/GTM)
Description includes specific trigger phrases a user would actually say
Description ends with negative triggers: "Do NOT use for X (use /alternative)"

Frontmatter includes

license: MIT

and

metadata: { author, version }

SKILL.md asks clarifying questions before producing output
Output is practical and actionable — not generic advice
Includes a
```
## Gotchas
```
section with 3-5 common Claude failure points for this domain
Doesn't state the obvious — focuses on info Claude wouldn't know
Avoids railroading — uses "typically" instead of "always", gives Claude flexibility
Reference material >500 words moved to
```
references/
```
directory
Deterministic operations (data fetching, formatting, validation) use scripts in
```
scripts/
```
Routing table in
```
sales-do/SKILL.md
```
updated with new row
README.md catalog table updated with new row
```
evals/evals.json
```
generated with 2-3 realistic test cases matching the skill-creator schema
Points to related skills where relevant

提交新Skill前（通过PR或skill-creator），请验证：

名称遵循仓库命名规范（销售类为
```
sales-<问题>
```
，营销/GTM类使用描述性名称）
描述包含用户实际会说的具体触发短语
描述包含负面触发条件：“Do NOT use for X (use /alternative)”

前置元数据包含

license: MIT

和

metadata: { author, version }

SKILL.md在生成输出前会提出澄清问题
输出实用且可执行——非通用建议
包含
```
## Gotchas
```
部分，列出3-5个该领域中Claude常见的失误点
不陈述显而易见的内容——聚焦Claude不知道的信息
避免强制流程——使用“通常”而非“必须”，给Claude灵活性
超过500字的参考资料已移至
```
references/
```
目录
确定性操作（数据获取、格式化、验证）使用
```
scripts/
```
目录中的脚本
```
sales-do/SKILL.md
```
中的路由表已添加新行
README.md中的目录表已添加新行
已生成
```
evals/evals.json
```
，包含2-3个符合skill-creator schema的真实测试用例
相关Skill已被正确关联

sales-request-skill

Original

Translation

Request or Build a Missing Sales Skill

请求或构建缺失的销售Skill

Step 1: Confirm the gap

步骤1：确认需求缺口

Step 2: Choose a path

步骤2：选择路径

Path A: Build the skill

路径A：构建Skill

Use skill-creator if available

若skill-creator可用

If skill-creator is NOT available

若skill-creator不可用

Write the SKILL.md

编写SKILL.md

Bad: too vague

反面示例：过于模糊

Good: specific triggers, covers edge cases

正面示例：明确触发短语，涵盖边缘场景

Test the skill

测试Skill

Submit the PR

提交PR

Summary

摘要

Files

文件

Path B: Request the skill

路径B：请求Skill

Problem

问题

Category

分类

Example use case

示例使用场景

Suggested trigger phrases

建议触发短语

Quality checklist

质量检查清单

Related skills

相关Skill

sales-request-skill

Original

Translation

Request or Build a Missing Sales Skill

请求或构建缺失的销售Skill

Step 1: Confirm the gap

步骤1：确认需求缺口

Step 2: Choose a path

步骤2：选择路径

Path A: Build the skill

路径A：构建Skill

Use skill-creator if available

若skill-creator可用

If skill-creator is NOT available

若skill-creator不可用

Write the SKILL.md

编写SKILL.md

Bad: too vague

反面示例：过于模糊

Good: specific triggers, covers edge cases

正面示例：明确触发短语，涵盖边缘场景

Test the skill

测试Skill

Submit the PR

提交PR

Summary

摘要

Files

文件

Path B: Request the skill

路径B：请求Skill

Problem

问题

Category

分类

Example use case

示例使用场景