Purpose
Turn scattered developer use-case inputs — interview notes, Slack threads, technical specs, and performance numbers — into a narrative case study that reads like a builder's journey rather than a feature brochure. Solves the problem of technical content that lists product capabilities but never makes another developer think "that's exactly my problem — I could build that too."
When to Use
Invoke this skill when the user asks to:
- Write a developer success story or customer case study
- Turn a company's build on the platform into publishable content
- Convert interview notes or a technical spec into a narrative story
- Create a case study that emphasizes the developer's decision-making, not just the outcome
- Produce technical content for a blog, docs site, or customer showcase page
- Draft a case study with a pull quote and metrics callout for marketing
Inputs Required
Before starting, collect:
- The builder: Company/team name, the developer(s) interviewed, and their role
- What they built: 2–4 sentence description of the product, feature, or system
- The original challenge: The technical or business problem they faced before adopting the platform
- The platform's role: Which product/API/SDK they used and what it replaced or enabled
- Technical details: Stack, architecture, integration points, any interesting engineering decisions or tradeoffs
- Impact metrics: Quantified results — latency, dev-hours saved, scale numbers, cost reduction, time-to-launch
- Direct quotes: Any verbatim developer statements from an interview or written source
If impact metrics are missing, flag it — a case study without at least one concrete number is significantly weaker. If direct quotes are missing, note that a real quote should be gathered before publication.
Instructions
Step 1: Identify the Story Spine
Before writing, extract the single narrative through-line. A case study is not a feature list — it's a decision under pressure.
- The stakes: What was at risk or blocked before? (A launch deadline, a scaling wall, a maintenance burden, a bad developer experience)
- The turning point: The moment the team decided to change approach or adopt the platform
- The payoff: What became possible that wasn't before Write these three as one sentence each. This is the skeleton every section serves. Do not proceed until the spine is clear.
Step 2: Write the Hook (Opening)
Open in the middle of the tension, not with corporate context. Two effective patterns:
- The wall: Start with the specific technical problem that stopped them cold ("The dashboard was returning stale data because the sync job couldn't keep up past 10,000 events per second.")
- The stakes: Start with what was on the line ("Six weeks before launch, the auth flow still didn't support enterprise SSO.") Avoid opening with company boilerplate, mission statements, or "Founded in 20XX." Earn the reader's attention with a real problem in the first two sentences.
Step 3: Establish the Challenge
Expand the problem so a peer developer feels it. Include:
- The technical constraint or business pressure in concrete terms
- What they tried first (build in-house, another tool, manual process) and why it fell short
- The cost of the status quo — engineering time, reliability, opportunity Show the problem was non-trivial. If it was easy, there's no story.
Step 4: Tell the Solution as a Decision, Not a Feature Dump
Frame the platform adoption as a series of choices the team made:
- Why this platform: What made it the right fit — specific capabilities, not marketing claims
- How they built it: The integration path, architecture, and any interesting engineering decisions or tradeoffs (what they optimized for, what they deprioritized)
- The moment it clicked: A specific point where the approach proved out Include a short architecture summary — 3–5 sentences or a labeled component list describing how the pieces fit together. Use real technical vocabulary; the reader is a developer.
Step 5: Quantify the Impact
State results with numbers wherever possible. Structure as before → after:
- Performance (latency, throughput, uptime)
- Velocity (time-to-launch, dev-hours reclaimed, deploy frequency)
- Business (cost, scale reached, customers unblocked) Frame each metric against the challenge from Step 3 so the payoff lands. Avoid unquantified claims like "much faster" — attach a number or a specific qualitative outcome.
Step 6: Add the Human Layer
Weave in the developer's voice:
- Select or lightly clean the strongest direct quote for a pull quote — it should express a feeling or realization, not restate a metric
- Reference the team's experience: what was satisfying, surprising, or relieving about the build This is what separates a case study from a spec sheet.
Step 7: Close with Forward Motion
End with where they're headed next — what they're building on top of this, what the platform unlocked for their roadmap. This signals the story isn't a dead end and models an ongoing relationship for the reader.
Output Format
- Structure: Narrative long-form article with an embedded pull quote, an architecture summary block, and a metrics callout
- Length: 700–1,100 words
- Format: Prose with a headline, one dek/subhead, section flow, one blockquote pull quote, and a scannable metrics callout (bulleted or short list)
- Sections: Headline + dek → Hook → The Challenge → The Solution (with architecture summary) → The Impact (metrics callout) → Pull quote (placed near the payoff) → What's Next
- Tone: Peer-to-peer developer voice — specific, technically literate, low on hype. Confident but not promotional; the platform is the tool, the developer is the protagonist.
Quality Checklist
Before delivering output, verify:
- [ ] The opening leads with a problem or stakes, not company boilerplate
- [ ] At least one quantified impact metric appears in a before → after frame (or the absence is flagged)
- [ ] The architecture summary uses real technical vocabulary and describes how components connect
- [ ] The pull quote expresses a realization or feeling, not a restated statistic
- [ ] The platform is positioned as the tool that enabled the developer — the developer is the protagonist
- [ ] No unquantified filler claims ("much faster," "way easier") without a number or specific outcome attached
Notes
- The most common failure mode is a feature list disguised as a story — if every paragraph is about the platform and none is about the developer's decision, restructure around Step 1's spine.
- If the raw inputs are thin, prioritize the challenge and the turning point over the technical detail; a vivid problem carries a case study further than an exhaustive stack rundown.
- When quotes are lightly cleaned for readability, preserve the developer's original meaning and technical accuracy — never invent a quote.
- A strong headline names the outcome and the builder ("How Acme cut sync latency 8x on the Events API"), not the platform's feature set.
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills