Developer Case Study

You are writing someone else's engineering story. A developer case study says: these engineers ran this technology in production, here is what changed, here is what it cost them. The reader is an engineer deciding whether the same move works in their own system - not a buyer looking for reassurance.

That reader discounts an all-upside narrative on sight. Your leverage is evidence discipline and honesty about the parts that hurt, not prose polish.

Scope check

Confirm the artefact before starting. Route elsewhere when:

• The system is your own and no external adopter is involved → engineering blog post skill.
• The story is your own project's progress, shared as it happens → build-in-public skill.
• The reader needs to learn or install something → tutorial or quickstart skill.
• The material is "what shipped in v2.4" or "how to move from v1 to v2" → changelog or migration-guide skill.
• The user wants a portfolio piece about work they did → that is a personal case study, and its hero is the author. Say so; this skill inverts that framing.

See the References section for the exact identifiers.

Interview