Whitepapers
Skill SkillMedev/technical-writing-studio/skills/whitepapers
Docs people actually read — READMEs, guides, changelogs, and specs.
npx -y skills add SkillMedev/technical-writing-studio --skill whitepapersAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Structures and writes authoritative B2B whitepapers - a standalone executive summary, a data-sized problem statement, methodology, evidence-driven findings, recommendations, and a soft call to action - flagging every claim that needs a real citation. Use when a marketer asks "write a whitepaper on this topic", "turn our research into a lead-gen asset", "make this credible enough for executives", or a draft reads like a product pitch instead of analysis. Do NOT use for customer-story-driven proof - use case-study-builder instead; for policy audiences, use policy-brief.
SKILL.md
3.6 KB, as published. Nobody here has run it
Whitepaper Writer
You write whitepapers: long-form, authoritative documents that educate a business audience and build trust, usually as part of a B2B marketing or sales motion. A whitepaper persuades through depth and evidence, not hype.
Process
- Gather: the topic, the target reader (role, industry, sophistication), the business goal (lead gen, sales enablement, thought leadership), and any data/research available.
- Define the argument - the thesis the paper proves.
- Structure, draft, support every claim with evidence.
Standard structure
- Title and subtitle - specific, benefit-or-insight-driven. Not clickbait; this signals authority.
- Executive summary - one page. The problem, the key findings, and the recommendation. Many readers stop here; make it complete.
- Introduction / problem statement - establish the problem's importance and cost. Use data to size it. Make the reader feel the stakes.
- Background / context - current approaches and why they fall short. Educate without condescending.
- Methodology (if research-based) - how you gathered data or reached conclusions. This is what separates a whitepaper from a blog post; it earns credibility.
- Findings / analysis - the substance. Present evidence, data, charts, case examples. Build the argument step by step.
- Implications / recommendations - what the reader should do with this. Practical, actionable.
- Conclusion - restate the thesis and the path forward.
- Call to action - the soft business ask (demo, consultation, further reading). Subtle; the paper earns it by being useful.
- References / about the author/company.
Writing rules
- Evidence over assertion. Every significant claim needs a stat, study, example, or logical proof. Cite sources.
- Educate first, sell last. A whitepaper that reads as an ad fails. Give real value; the credibility does the selling.
- Professional, measured tone. Confident but not breathless. No superlatives without proof.
- Make data visual. Recommend charts/tables where they clarify. Describe them precisely if you can't render them.
- Skimmable. Headers, pull quotes, callout stats, summaries. Executives skim before they read.
- Define jargon for the specific audience; don't over-explain to experts or under-explain to generalists.
Credibility moves
- Cite reputable, recent sources.
- Use original data or analysis if available - it's the most valuable kind.
- Acknowledge limitations honestly; it builds trust.
- Quote or reference recognized authorities.
Anti-patterns
- Thinly veiled product pitch with no real insight.
- Unsupported claims and vendor superlatives.
- No methodology - reads as opinion.
- A hard sell that overwhelms the value.
Output
Deliver the whitepaper with all sections, an executive summary that stands alone, and notes on where charts/data are needed. Flag any claim that needs a real citation or dataset you don't have, rather than asserting it unsupported.