developer-case-study

Turns customer production deployments into evidence-backed technical case studies with measured numbers and cleared approvals.

2|Updated Sep 6, 2026
One-click install
npx skills add https://github.com/samber/developer-relations-skills --skill developer-case-study-samber
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: developer-case-study
Source: https://github.com/samber/developer-relations-skills/tree/main/skills/developer-case-study
Command: npx skills add https://github.com/samber/developer-relations-skills --skill developer-case-study-samber

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Customer case studies aimed at engineers usually collapse into testimonials: unverified numbers, paraphrased quotes, no limitations, and approval chains that stall or blow up after drafting. This Skill turns a real production deployment into a technical case study engineers trust, with every claim classified by evidence class, every number tied to an instrument and measurement window, and naming, quote, and security approvals cleared before publication. ## Core Features & Use Cases - Story qualification and ranking: Five gates (production not pilot, measured before-state, a named human, a reusable decision, a path to approval) decide whether a story is publishable, and an efficiency ranking picks which adopter to chase first when several candidates exist. - Evidence discipline: An evidence ledger classifies every claim as measured, partially measured, reported, or directional, and blocks annualized figures, unconfirmed derived percentages, and numbers the customer cannot vouch for. - Approval and anonymization workflow: A four-permission consent chain, pre-redaction of what security review predictably strikes, and a five-rung anonymization ladder for when naming is refused. - Use Case: You finished migrating a customer's billing pipeline onto your workflow engine and have a call recording plus a metrics screenshot. The Skill produces a verdict, an evidence ledger, an eight-section draft with verbatim quotes and a limitations section, an approval package with a dated deadline, and a seven-check gate report before anything ships. ## Quick Start Ask the assistant to write a technical case study from your customer interview transcript and metrics, and have it produce the verdict and evidence ledger before drafting.

Frequently Asked Questions about developer-case-study

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a technical case study engineers will trust?▼

Qualify the story against five gates first, then build an evidence ledger classifying every claim as measured, partially measured, reported, or directional before drafting. Draft on an eight-section spine that includes rejected alternatives and a limitations section, and keep every quote verbatim from the recorded interview.

What should a developer case study include besides challenge, solution, and results?▼

Add three sections the standard template omits: alternatives weighed and rejected, metric provenance stating the instrument and measurement window next to each number, and a limitations section naming real costs like migration effort, dual-running periods, and workloads deliberately not moved.

Can I publish a customer case study if our contract has a logo clause?▼

A logo clause covers only the company name, logo, and the fact of being a customer. Quotes, metrics, architecture descriptions, and narratives about their systems each need separate permission, often from four different holders: the engineer, their manager, communications, and security or legal.

What do I do when a customer refuses to be named in a case study?▼

Descend an anonymization ladder one rung at a time: named company with unnamed engineer, then unnamed company with an identifying descriptor, then category descriptor only. Never sharpen a descriptor until the company is re-identifiable, and treat the bottom rung, a pattern write-up, as no longer a case study.

When should I not use a customer case study format?▼

Do not use it for stories about your own system, which belong in an engineering blog post, or for ongoing progress updates, which fit build-in-public. A story still in evaluation rather than production fails the qualification gates and should wait rather than be published as a testimonial.

How do I measure whether a case study program is working?▼

Judge studies on whether they move evaluations forward, not on traffic or attributed revenue. Track use in live deals, read-through to linked docs and repositories, inbound reference requests, whether the adopter's own engineers share it, and coverage across use cases and adopter sizes.