--- name: sales-request-skill description: "Requests or contribute a new sales/marketing/GTM skill that doesn't exist yet, or share learnings discovered during skill usage back to the community. Use when no existing skill covers the user's need — helps them build the skill and submit a PR, or file an issue requesting it. Also use when the user says 'there should be a skill for this', 'can we make a skill', 'I want to contribute a skill', 'none of the sales skills cover my use case', 'share my learnings', 'contribute learnings', 'share what I learned', or 'push learnings upstream'." argument-hint: "[describe the missing capability]" version: 1.0.0 tags: [sales, meta, skill-request] --- # 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-` 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.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: description: ". Use when . Do NOT use for (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": "", "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-` 4. Stage and commit: `git add skills// evals/ skills/sales-do/SKILL.md README.md && git commit -m "Add skill"` 5. Push: `git push -u origin add-` 6. Open the PR: ```bash gh pr create \ --repo sales-skills/sales \ --title "Add skill" \ --body "$(cat <<'EOF' ## Summary - **Problem**: - **Category**: - **Example invocation**: `/ ` ## Files - `skills//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: " \ --body "$(cat <<'EOF' ## Problem ## Category ## Example use case ## 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: ```bash 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 (``) or declined (``) 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: ```python 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 `` to learnings the user submitted - **Declined**: append `` 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-` 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`