sales-request-skill

What this skill does

# Request or Build a Missing Sales 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
- **Path C (Share Learnings)**: Scan local learnings, scrub PII, and open a **GitHub issue** for each skill with shareable discoveries

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

## Step 1: Confirm the gap

If `$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.)

## Step 2: Choose a path

Ask the user:

> Would you like to:
> 1. **Build the skill** — I'll help you create it with proper structure and prepare a PR
> 2. **Request the skill** — I'll file a GitHub issue so the maintainers know it's needed
> 3. **Share learnings** — I'll scan your installed skills for discoveries, scrub personal details, and share them back to the repo

## Path A: Build the skill

### Use skill-creator if available

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):
> 1. Step to gather context (ask 2-4 questions about the user's specific situation)
> 2. Implementation steps with actionable output
> 3. Templates or frameworks relevant to the problem domain
> 4. Gotchas section with 3-5 common Claude failure points for this domain
> 5. Output formatting guidance
> 6. 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.

### If skill-creator is NOT available

Build the skill manually following the conventions above.

#### Write the 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
# 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."
```

**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.

#### Test the 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.

### Submit the PR

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

1. Update `skills/sales-do/SKILL.md` — add a row to the appropriate routing table
2. Update `README.md` — add a row to the appropriate catalog table
3. Create a branch: `git checkout -b add-<skill-name>`
4. Stage and commit: `git add skills/<skill-name>/ evals/ skills/sales-do/SKILL.md README.md && git commit -m "Add <skill-name> skill"`
5. Push: `git push -u origin add-<skill-name>`
6. Open the 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>`

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

## Path B: Request the 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'
## 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