sales-request-skill

请求或构建缺失的销售技能

用户需要一项尚无对应技能的销售、营销或 GTM 能力。帮助他们贡献该技能或提出请求。

此技能始终以 GitHub 上的具体操作结束：

• 路径 A（构建）：创建技能文件，提交更改、推送，并向 sales-skills/sales 发起拉取请求
• 路径 B（请求）：在 sales-skills/sales 上提交 GitHub issue，描述所需内容
• 路径 C（分享经验）：扫描本地经验，清除个人身份信息（PII），并为每项有可分享发现的技能提交一个 GitHub issue

不要只停留在“PR/issue 应该是什么样”——要使用 gh pr create 或 gh issue create 实际创建。

步骤 1：确认缺口

如果提供了 $ARGUMENTS，请使用它。否则询问：“你需要哪种现有技能尚未涵盖的销售、营销或 GTM 能力？”

确认请求属于销售/营销/GTM 领域。如果完全超出范围（例如“构建数据库迁移工具”），请说明情况并推荐合适的工具。

查看 skills/sales-do/SKILL.md 中的路由表，并列出 ~/.claude/skills/ 中已安装的技能，确认没有现有技能已经涵盖该需求。如果有相近的技能，请改为推荐该技能。

向用户概述：

• 他们的需求：用一句话说明
• 最接近的现有技能：说明哪些方面相近，但不完全符合需求
• 类别：该技能所属的部分（潜在客户开发与销售管道、推进中的交易、战略与内容、营销与 GTM、研究与数据、创意与设计等）

步骤 2：选择路径

询问用户：

你希望：

1. 构建技能——我会帮助你创建符合规范的结构并准备 PR
2. 请求技能——我会提交 GitHub issue，让维护者了解这一需求
3. 分享经验——我会扫描已安装的技能，寻找新发现，清除个人信息，并将经验分享回仓库

路径 A：构建技能

如果有 skill-creator，请使用它

检查 /skill-creator 技能是否可用。如果可用，请委托它完成完整的创建、测试和迭代工作流。

委托给 /skill-creator 时，请提供以下销售领域的背景信息：

此技能的仓库约定：

• 命名：销售技能使用 sales-<problem>，营销/GTM 技能使用描述性名称（例如 cold-email、launch-strategy）
• 描述应使用销售人员和营销人员实际会说的短语，例如“写一封冷邮件”“为探索性沟通做准备”“处理这个异议”
• 描述必须以否定触发条件结尾：Do NOT use for X (use /alternative)
• SKILL.md 是唯一必需的文件——内容应聚焦且可执行
• 技能应在执行前提出澄清问题（受众、阶段、限制条件）
• 技能应通过 /sales-do 路由——路由器根据描述字段决定何时匹配

技能结构：

skills/<skill-name>/
├── SKILL.md        # 主要说明（必需）
├── scripts/        # 确定性操作（数据获取、验证、格式化）
├── references/     # 大型参考资料（>500 字——API 文档、数据模型）
├── assets/         # 模板、示例、配置文件
└── evals/
    └── evals.json  # 测试用例（可选，由 skill-creator 生成或手动编写）

SKILL.md 正文模式（遵循此仓库中其他技能的做法）：

1. 收集背景信息的步骤（询问用户 2-4 个关于其具体情况的问题）
2. 可生成可执行成果的实施步骤
3. 与问题领域相关的模板或框架
4. 易错点部分，列出该领域中 Claude 常见的 3-5 个失败点
5. 输出格式指导
6. 指向相关技能的后续步骤

关键原则：

• 避免陈述显而易见的内容：聚焦于 Claude 不会知道的信息——内部约定、领域易错点和非显而易见的模式
• 避免生搬硬套：使用“通常”而不是“总是”。给 Claude 灵活调整的空间
• 脚本：如果技能涉及确定性操作（数据获取、格式化、验证），请在 scripts/ 中加入脚本
• 渐进式披露：将超过 500 字的参考资料移至 references/ 目录

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

如果 skill-creator 不可用

请遵循上述约定手动构建技能。

编写 SKILL.md

---
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
version: 1.0.0
tags: [sales, <category>]
---

阅读 skills/ 中 2-3 个现有技能，以匹配语气和结构。以下几点尤其需要注意：

Description 字段——/sales-do 路由器和 Claude 会据此判断是否使用该技能。请具体说明触发短语，并同时说明技能的作用和适用时机：

# Bad: too vague
description: "Help with sales emails"

# 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."

正文——应遵循先提问的模式：在生成内容前，先了解用户的具体情况。加入模板、框架或示例，让输出能立即派上用场。

测试技能

在新技能目录中生成 evals/evals.json 文件，其中包含 2-3 个真实的测试用例。每个评估项都应模拟销售人员或营销人员实际会提出的请求，并列出描述优质回复的断言。

{
  "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"}
      ]
    }
  ]
}

在技能启用的情况下运行评估提示词，并确认输出符合断言。这与 /skill-creator 使用的架构一致，因此无论采用哪种构建方式，评估都能以相同方式运行。

提交 PR

创建技能文件后，提交拉取请求。完成以下所有步骤——不要只停留在“告诉用户该怎么做”：

1. 更新 skills/sales-do/SKILL.md——在相应的路由表中添加一行
2. 更新 README.md——在相应的目录表中添加一行
3. 创建分支：git checkout -b add-<skill-name>
4. 暂存并提交：git add skills/<skill-name>/ evals/ skills/sales-do/SKILL.md README.md && git commit -m "Add <skill-name> skill"
5. 推送：git push -u origin add-<skill-name>
6. 创建 PR：

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>`

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

完成后将 PR URL 返回给用户。

路径 B：申请技能

在仓库中提交 GitHub issue。不要只起草——要实际提交：

gh issue create \
  --repo sales-skills/sales \
  --title "Skill request: <skill-name>" \
  --body "$(cat <<'EOF'
## Problem
<What the user is trying to do, in their words>

## Category
<Which section this fits in: Prospecting, Active Deals, Strategy, Marketing, Research, Creative, etc.>

## Example use case
<A concrete scenario where this skill would help>

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

完成后将 issue URL 返回给用户。

路径 C：分享经验

随着用户发现 API 特性、定价变化、变通方法和注意事项，经验会累积在各个已安装技能的 references/learnings.md 文件中。此路径会扫描这些文件、清除个人身份信息，并创建 GitHub issue，让个人发现的问题能帮助所有人改进技能。

步骤 C1——扫描已安装的技能

查找所有经验文件：

find ~/.claude/skills/*/references/learnings.md 2>/dev/null

阅读每个文件。跳过：

• 空白模板（除初始模板外没有任何内容的文件）
• 已标记为已分享（）或已拒绝（）的条目

如果用户提到了特定技能或平台（例如，“我发现了 Apollo 的一些注意事项”），请予以回应，并说明扫描会找出该技能以及其他技能的经验。

如果所有已安装技能中都没有未分享的经验，请告诉用户：

未发现未分享的经验。随着你使用技能，经验会自动累积——当你发现 API 特性、变通方法或注意事项时，它们会追加到每个技能的 references/learnings.md 中。使用一段时间后，欢迎再来查看。

如果没有发现任何内容，到此为止。

步骤 C2——展示并分类

对于每个包含未分享经验的技能，展示一个表格：

#	经验	是否具有普遍适用性？	原因
1	...	是/否	...

具有普遍适用性（分享这些内容）：

• API 特性、未记录的行为或端点变更
• 文档中未提及的定价变化或限制
• 平台缺陷的变通方法
• 配置注意事项或不明显的默认设置
• 工具之间的集成问题
• 速率限制、流量限制或配额详情

不具有普遍适用性（跳过这些内容）：

• 公司名称、团队结构、内部工作流
• 个人偏好或组织特有的自定义字段
• 仅适用于某个组织的内部工具配置
• 特定账户协商的定价或合同

请用户确认或修改分类，然后再继续。

步骤 C3——清除个人身份信息

对于每条具有普遍适用性的经验，查找并替换个人身份信息：

查找	替换为
公司或域名	[Company]、[domain]
人名	[Name]
电子邮件地址	[email]
GitHub/社交媒体用户名	[handle]
账户、API 或工作区 ID	[account-id]
内部 URL 或 IP 地址	[internal-url]
协商得出的或非公开定价	完全删除（只保留公开记录的定价）
客户名称	[customer]
特定团队名称	[team]（保留“销售”“营销”“工程”等通用名称）

展示每条已清除信息的修改前后内容，并请用户确认清除后的版本正确无误，然后再继续。

步骤 C4 — 创建 GitHub issue 以供审核

每项技能创建一个 issue（聚焦且可独立合并）。不要自动提交——在浏览器中打开预先填写好的 issue，供用户审核。

对于每项包含可分享经验的技能，构建一个 GitHub issue URL：

• 标题：Learnings: sales-{skill-name}
• 标签：learnings
• 正文：以便于复制粘贴的格式列出每条已清理的经验，并附上技能版本和提交方式的背景信息

将标题、正文和标签进行 URL 编码，组成 GitHub 新建 issue 的 URL：

https://github.com/sales-skills/sales/issues/new?title=...&body=...&labels=learnings

在浏览器中打开每个 URL：

import subprocess
subprocess.run(['open', '-na', 'Google Chrome', '--args', '--profile-directory=Profile 6', url])

绝不要通过 gh issue create 自动提交经验——用户必须先审核已清理的内容，再将其公开。

步骤 C5 — 标记为已处理

用户确认已提交 issue 后，将每条经过审核的经验标记为：

• 已分享：在用户提交的经验后追加 ``
• 已拒绝：在用户归类为不可泛化或选择不分享的经验后追加 ``

这样可以避免在后续运行中再次提示相同的经验。

质量检查清单

提交新技能之前（通过 PR 或 skill-creator），请确认：

• 名称遵循仓库约定（销售类使用 sales-<problem>，营销/GTM 类使用描述性名称）
• 描述包含用户实际会说的具体触发短语
• 描述以否定触发条件结尾：“不要用于 X（请使用 /alternative）”
• Frontmatter 包含 license: MIT 和 metadata: { author, version }
• SKILL.md 要求先提出澄清问题，再生成输出
• 输出实用且可执行，而非泛泛建议
• 包含 ## Gotchas 部分，列出该领域中 3-5 个 Claude 常见的失误点
• 不陈述显而易见的内容——重点介绍 Claude 不会知道的信息
• 避免限制过死——使用“通常”而不是“始终”，给 Claude 留出灵活处理的空间
• 将超过 500 词的参考资料移至 references/ 目录
• 确定性操作（数据获取、格式化、验证）使用 scripts/ 中的脚本
• 更新 sales-do/SKILL.md 中的路由表，添加新行
• 更新 README.md 目录表，添加新行
• 按照 skill-creator 架构生成 evals/evals.json，包含 2-3 个真实测试用例
• 在相关时指向相关技能

示例

示例 1：端到端构建缺失的技能

用户说：“应该有一个撰写季度业务回顾的技能——现有技能都不涵盖这方面。我们能做一个吗？”

技能执行：

1. 确认缺口（步骤 1）：检查 skills/sales-do/SKILL.md 中的路由表和 ~/.claude/skills/，发现没有 QBR 技能，并总结需求、最接近的现有技能以及类别（策略与内容）。
2. 提供三种途径（步骤 2）；用户选择构建。
3. 如果有 /skill-creator，则委托给它，并传入仓库约定（命名、包含否定触发条件的描述、先提问的正文、Gotchas 部分）。
4. 编写 skills/qbr-prep/SKILL.md，以及包含 2-3 个真实测试用例的 evals/evals.json，并运行测试。
5. 更新 skills/sales-do/SKILL.md 和 README.md，创建分支、提交、推送，并对 sales-skills/sales 运行 gh pr create。

结果：新增技能目录、通过测试的 eval 文件、更新后的路由表和目录表，以及返回给用户的有效拉取请求 URL。

示例 2：用户目前无法构建的技能请求

用户说：“我想要一个用于管理渠道合作伙伴联合销售交易的技能，但我没时间构建。”

技能执行：

1. 确认缺口，并验证其符合销售/营销/GTM 领域。
2. 用户选择 Request（途径 B）。
3. 在 sales-skills/sales 上运行 gh issue create，填写问题描述、类别、示例用例和 2-3 个建议触发短语。

结果：GitHub issue 已提交，并返回其 URL——没有草稿留在聊天中。

示例 3：分享使用技能时发现的经验

用户说：“我在开发潜在客户时发现了一些 Apollo 速率限制方面的注意事项——把我的经验反馈到上游。”

技能执行：

1. 扫描 ~/.claude/skills/*/references/learnings.md，跳过空白占位文件以及已标记为 或 的条目。
2. 在“是否具有普遍适用性？”表格中列出每条经验，并请用户确认分类。
3. 清除个人身份信息（PII）（公司名称、电子邮件、账号 ID、协商价格），并展示修改前后的内容以供审批。
4. 为每项技能构建一个经过 URL 编码的 GitHub 新建 issue 链接，并在浏览器中打开以供审核——绝不通过 gh 自动提交。
5. 用户确认提交后，为每条已处理的经验追加 或。

结果：每项技能都有一个审核就绪的 issue，其中包含已清除敏感信息的公开内容；本地经验也已标记，因此不会再次提示。

故障排除

技能一直提议构建，而不是先确认需求缺口

原因：跳过了步骤 1（确认需求缺口），因此可能已有一个足够匹配的技能可以满足请求，却又提议创建重复技能。

解决方案：在提供方案前，务必检查 skills/sales-do/SKILL.md 中的路由表以及 ~/.claude/skills/ 中已安装的技能。如果有接近匹配的技能，请推荐该技能，而不是新建技能。

gh pr create 或 gh issue create 因身份验证或权限错误而失败

原因：gh CLI 尚未通过身份验证，或用户没有对 sales-skills/sales 的推送权限。

解决方案：运行 gh auth status 确认登录状态；如果尚未通过身份验证，请提示用户运行 gh auth login。如果用户无法推送到上游仓库，请 fork 该仓库，将分支推送到 fork，并从那里创建 PR；或者改用路径 B（提交 issue），以便记录该请求。

分享经验时未找到任何内容，或显示了已分享过的条目

原因：所有经验文件都是空白占位文件，或者条目已带有 / 标记，而扫描会有意跳过这些条目。

解决方案：这是预期行为——告知用户经验会随着技能的使用逐渐积累，请稍后再来。切勿重新分享带有标记的条目；如果先前被拒绝的经验现在具有普遍适用性，请在重新扫描前手动移除其标记。

相关技能

• /sales-do — 不确定该使用哪个技能？路由器会将任何销售目标匹配到合适的技能。安装：npx skills add sales-skills/sales --skill sales-do