sales-skills/sales-request-skill

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

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

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

{
  "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:

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:

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
)"

Return the issue URL to the user when done.

Path C: Share learnings

Learnings accumulate in references/learnings.md files inside each installed skill as users discover API quirks, pricing changes, workarounds, and gotchas. This path scans those files, scrubs PII, and opens GitHub issues so individual discoveries can improve the skills for everyone.

Step C1 — Scan installed skills

Find all learnings files:

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

Read each file. Skip:

• Empty stubs (files with no content beyond the initial template)
• Entries already marked as shared (<!-- shared:YYYY-MM-DD -->) or declined (<!-- declined:YYYY-MM-DD -->)

If the user mentioned a specific skill or platform (e.g., "I found some Apollo gotchas"), acknowledge it and note that the scan will surface that skill's learnings alongside any others found.

If no unshared learnings are found across any installed skill, tell the user:

No unshared learnings found. Learnings accumulate automatically as you use skills — when you discover API quirks, workarounds, or gotchas, they get appended to each skill's references/learnings.md. Come back after you've used some skills for a while.

Stop here if nothing is found.

Step C2 — Present and classify

For each skill that has unshared learnings, present a table:

| # | Learning | Generalizable? | Reason | |---|----------|---------------|--------| | 1 | ... | Yes/No | ... |

Generalizable (share these):

• API quirks, undocumented behavior, or endpoint changes
• Pricing changes or limits not reflected in docs
• Workarounds for platform bugs
• Configuration gotchas or non-obvious defaults
• Integration issues between tools
• Rate limits, throttling, or quota details

Not generalizable (skip these):

• Company names, team structures, internal workflows
• Personal preferences or org-specific custom fields
• Internal tool configurations specific to one organization
• Account-specific negotiated pricing or contracts

Ask the user to confirm or override the classifications before proceeding.

Step C3 — Scrub PII

For each generalizable learning, find and replace personally identifiable information:

| Find | Replace with | |------|-------------| | Company or domain names | [Company], [domain] | | People names | [Name] | | Email addresses | [email] | | GitHub/social handles | [handle] | | Account, API, or workspace IDs | [account-id] | | Internal URLs or IP addresses | [internal-url] | | Negotiated or non-public pricing | Remove entirely (keep only publicly documented pricing) | | Customer names | [customer] | | Specific team names | [team] (keep generic ones like "Sales", "Marketing", "Engineering") |

Show before/after for each scrubbed learning and ask the user to confirm the scrubbed versions look correct before proceeding.

Step C4 — Open GitHub issue for review

Create one issue per skill (focused, independently mergeable). Do not auto-submit — open the pre-filled issue in the browser for user review.

For each skill with shareable learnings, build a GitHub issue URL:

• Title: Learnings: sales-{skill-name}
• Labels: learnings
• Body: list each scrubbed learning in copy-paste-ready format, plus context about the skill version and submission method

URL-encode the title, body, and labels into a GitHub new-issue URL:

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

Open each URL in the browser:

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

Never auto-submit via gh issue create for learnings — the user must review the scrubbed content before it goes public.

Step C5 — Mark as processed

After the user confirms they've submitted the issue(s), mark every learning that was reviewed:

• Shared: append <!-- shared:YYYY-MM-DD --> to learnings the user submitted
• Declined: append <!-- declined:YYYY-MM-DD --> to learnings the user classified as not generalizable or chose not to share

This prevents re-prompting the same learnings on future runs.

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

Related skills

• /sales-do — Not sure which skill to use? The router matches any sales objective to the right skill. Install: npx skills add sales-skills/sales --skill sales-do