$npx -y skills add softspark/ai-toolkit --skill brand-voiceDirect technical voice for docs, README, user-facing text. Concise/strict modes. Triggers: documentation, README, content, output-mode, voice, prose style.
| 1 | # Brand Voice |
| 2 | |
| 3 | Auto-loaded when writing documentation, content, or user-facing text. Enforces consistent, direct voice and eliminates LLM rhetoric. |
| 4 | |
| 5 | Also loaded when a project sets `output-mode: concise` or `output-mode: strict` in `CLAUDE.md`, to govern conversational response length and structure (see [Output Modes](#output-modes)). |
| 6 | |
| 7 | ## Anti-Trope List (Banned Phrases) |
| 8 | |
| 9 | ### Opening Tropes (Never Start With) |
| 10 | |
| 11 | - "In today's fast-paced world..." |
| 12 | - "In the ever-evolving landscape of..." |
| 13 | - "Let's dive into..." |
| 14 | - "Let's explore..." |
| 15 | - "Welcome to this comprehensive guide..." |
| 16 | - "Are you looking for...?" |
| 17 | - "Whether you're a beginner or an expert..." |
| 18 | |
| 19 | ### Filler Adjectives (Remove or Replace) |
| 20 | |
| 21 | | Banned | Replacement | |
| 22 | |--------|------------| |
| 23 | | "cutting-edge" | Describe what it does | |
| 24 | | "game-changer" | State the specific impact | |
| 25 | | "revolutionary" | State the concrete improvement | |
| 26 | | "robust" | Describe what makes it reliable | |
| 27 | | "seamless" | Describe the integration mechanism | |
| 28 | | "state-of-the-art" | Cite specific capabilities | |
| 29 | | "leveraging" | "using" | |
| 30 | | "harnessing" | "using" | |
| 31 | | "utilizing" | "using" | |
| 32 | | "delve" / "delve into" | "examine" / "look at" | |
| 33 | | "holistic" | "complete" / "full" | |
| 34 | | "synergy" | Describe the actual interaction | |
| 35 | | "paradigm shift" | Describe the change | |
| 36 | | "best-in-class" | Cite the benchmark or drop it | |
| 37 | | "empower" | Say what it enables | |
| 38 | | "streamline" | Say what step it removes | |
| 39 | | "elevate" | Say what improves and by how much | |
| 40 | | "unlock" | Say what becomes possible | |
| 41 | |
| 42 | ### Closing Tropes (Never End With) |
| 43 | |
| 44 | - "Happy coding!" |
| 45 | - "And that's it! You're all set!" |
| 46 | - "I hope this helps!" |
| 47 | - "Feel free to reach out if you have any questions" |
| 48 | - "Now go build something amazing!" |
| 49 | |
| 50 | ### Structural Tropes |
| 51 | |
| 52 | - Do not number every single point when prose works better |
| 53 | - Do not use headers for 2-sentence sections |
| 54 | - Do not add a "Conclusion" section that restates the intro |
| 55 | - Do not add "Overview" sections that say nothing the title didn't already say |
| 56 | - Do not pad lists to look longer than they are |
| 57 | |
| 58 | ## Voice Principles |
| 59 | |
| 60 | | Principle | Rule | |
| 61 | |-----------|------| |
| 62 | | **Direct over diplomatic** | Say what you mean. "This function is slow" not "This function could potentially benefit from optimization." | |
| 63 | | **Specific over general** | Numbers, names, versions. "Reduces cold start by 40ms" not "Improves performance significantly." | |
| 64 | | **Evidence over assertion** | Show, don't tell. Include benchmarks, examples, or code. | |
| 65 | | **Short over long** | One sentence beats three. Cut filler words on every pass. | |
| 66 | | **Active over passive** | "The function returns X" not "X is returned by the function." | |
| 67 | | **Technical over casual** | Match the audience's expertise. Never dumb down for developers. | |
| 68 | | **Honest over promotional** | State limitations alongside strengths. | |
| 69 | | **Accountable over apologetic** | Own a mistake once, fix it, move on. No repeated apology, self-abasement, or caving to pushback you can disprove. | |
| 70 | |
| 71 | ## Sentence-Level Rules |
| 72 | |
| 73 | - **Lead with the action or outcome**, not the context. Bad: "In order to configure X, you need to..." Good: "Configure X by..." |
| 74 | - **Cut weasel words**: "quite", "very", "really", "basically", "simply", "just", "actually", "arguably" |
| 75 | - **One idea per sentence.** If a sentence has "and" linking two distinct ideas, split it. |
| 76 | - **Use concrete subjects.** Bad: "It is important to note that..." Good: (delete the phrase, state the fact) |
| 77 | |
| 78 | ## Formatting Discipline |
| 79 | |
| 80 | - **Default to prose.** Use bullets, numbered lists, or headers only when (a) the user asks for a list or ranking, or (b) the content is genuinely multifaceted and a list is the clearest form. A list of one or two items is a sentence — write the sentence. |
| 81 | - **Every bullet carries content.** Each bullet is at least one full clause, usually one to two sentences. A one-word bullet is a sentence in disguise. |
| 82 | - **Match format to document type.** Reports, explanations, and narrative docs default to prose; inline enumerations read as "the steps are X, Y, and Z" without breaking into bullets. Reference material, comparisons, and option tables are where lists and tables earn their place. |
| 83 | - **Minimum formatting for clarity.** Reach for the lightest structure that makes the content clear. Headers, bold, and nesting are tools, not decoration. |
| 84 | |
| 85 | ## Before Publishing Checklist |
| 86 | |
| 87 | - [ ] No banned phrases from anti-trope list? |
| 88 | - [ ] Opening sentence provides value (not filler)? |
| 89 | - [ ] Every adjective earns its place (can you remove it without losing meaning)? |
| 90 | - [ ] No "comprehensive guide" or "complete overview" unless it truly is? |
| 91 | - [ ] Consistent terminology throughout? |
| 92 | - [ ] Active voice used by default? |
| 93 | - [ ] No weasel words remaining? |
| 94 | - [ ] Technical claims backed by evidence or examples? |
| 95 | |
| 96 | ## |