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

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

Examples

Example 1: Build a missing skill end-to-end

User says: "There should be a skill for writing quarterly business reviews — none of the existing ones cover it. Can we make one?"

Skill does:

1. Confirms the gap (Step 1): checks the routing table in skills/sales-do/SKILL.md and ~/.claude/skills/, finds no QBR skill, and summarizes the need, the closest existing skill, and the category (Strategy & Content).
2. Offers the three paths (Step 2); the user picks Build.
3. Delegates to /skill-creator if available, passing the repo conventions (naming, description with negative triggers, question-first body, gotchas section).
4. Writes skills/qbr-prep/SKILL.md plus an evals/evals.json with 2-3 realistic test cases and runs them.
5. Updates skills/sales-do/SKILL.md and README.md, branches, commits, pushes, and runs gh pr create against sales-skills/sales.

Result: A new skill directory, a passing eval file, updated routing and catalog tables, and a live pull request URL returned to the user.

Example 2: Request a skill the user can't build now

User says: "I want a skill for managing channel-partner co-sell deals, but I don't have time to build it."

Skill does:

1. Confirms the gap and verifies it fits the sales/marketing/GTM domain.
2. The user chooses Request (Path B).
3. Runs gh issue create on sales-skills/sales with a filled-in problem statement, category, example use case, and 2-3 suggested trigger phrases.

Result: A GitHub issue is filed and its URL is returned — no draft left sitting in the chat.

Example 3: Share learnings discovered while using skills

User says: "I found some Apollo rate-limit gotchas while prospecting — push my learnings upstream."

Skill does:

1. Scans ~/.claude/skills/*/references/learnings.md, skipping empty stubs and entries already marked <!-- shared --> or <!-- declined -->.
2. Presents each learning in a Generalizable? table and asks the user to confirm the classification.
3. Scrubs PII (company names, emails, account IDs, negotiated pricing) and shows before/after for approval.
4. Builds a URL-encoded GitHub new-issue link per skill and opens it in the browser for review — never auto-submitting via gh.
5. After the user confirms submission, appends <!-- shared:YYYY-MM-DD --> or <!-- declined:YYYY-MM-DD --> to each processed learning.

Result: One review-ready issue per skill with scrubbed public content, and local learnings marked so they aren't re-prompted.

Troubleshooting

The skill keeps proposing to build instead of confirming the gap first

Cause: Step 1 (confirm the gap) was skipped, so a close-enough existing skill may already cover the request and a duplicate gets proposed.

Solution: Always check the routing table in skills/sales-do/SKILL.md and the installed skills in ~/.claude/skills/ before offering a path. If there's a close match, suggest that skill instead of building a new one.

gh pr create or gh issue create fails with an auth or permission error

Cause: The gh CLI isn't authenticated, or the user lacks push access to sales-skills/sales.

Solution: Run gh auth status to confirm login; if not authenticated, prompt the user to run gh auth login. If they can't push to the upstream repo, fork it, push the branch to the fork, and open the PR from there — or fall back to Path B (file an issue) so the request is still captured.

Share-learnings finds nothing, or surfaces entries that were already shared

Cause: All learnings files are empty stubs, or entries already carry a <!-- shared:YYYY-MM-DD --> / <!-- declined:YYYY-MM-DD --> marker, which the scan deliberately skips.

Solution: This is expected — tell the user learnings accumulate as skills are used and to return later. Never re-share marked entries; if a previously declined learning has become generalizable, remove its marker manually before re-running the scan.

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