Skip to content
Back to skills

Long Read Case Writer

ASecurity

Writes the long-read case study, 1,500 to 2,500 words in magazine shape, for the buyers who want to see how the firm thinks, part of the Case Study Factory Pack by Polar Bear. Use this whenever the user says "run long-read-case-writer", "write the long version", "the full case study", "a case study that shows our process", "portfolio case study", or when a design or strategy buyer needs more than a page. Use it even for "make the case study longer".

  • 2 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 4, 2026
ai-agentsrustgodocumentation

Works with

  • cli

Security analysis

A100/100

Scanned October 4, 2026

npx -y skills add polar-bear-org/claude-skills --skill long-read-case-writer --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Long Read Case Writer?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Long Read Case Writer
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/polar-bear-org-long-read-case-writer/badge)](https://www.skillsdirectory.com/skills/polar-bear-org-long-read-case-writer)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: long-read-case-writer
description: Writes the long-read case study, 1,500 to 2,500 words in magazine shape, for the buyers who want to see how the firm thinks, part of the Case Study Factory Pack by Polar Bear. Use this whenever the user says "run long-read-case-writer", "write the long version", "the full case study", "a case study that shows our process", "portfolio case study", or when a design or strategy buyer needs more than a page. Use it even for "make the case study longer".
---

# Long-Read Case Writer

Some buyers do not want proof that you delivered; they want to know how you decide. Design directors, heads of product, founders choosing a strategy partner: they read the long case to watch you think, and they trust the ones that show the wrong turn. The long read is a magazine feature, not documentation. It has a narrative with a problem that gets worse before it gets better, decisions with reasons, one or two things the reader did not know before, and images with captions that carry the story on their own. What it does not have is a process diagram, a list of deliverables, and the phrase "we then". The web case answers "is this us"; the long read answers "would I want these people in the room".

## How to work with me

Run me in the case's pinned chat in **Case Study HQ**, after `case-interviewer`, or on its own. This takes an hour with me and an hour of your editing, and the second hour matters more than the first. Bring the material list from the source file: a long read without images is an essay.

## Before starting

I read `case-source-[slug].md` for everything, and `firm-context.md` for the tone, the words never used, the naming level, and the voice sample. If the source file is not in the project, I run the ten-minute interview with you and mark the output "written from a short interview"; a long read from a short interview is thin, and I say so, and I list the questions a second conversation should answer. If firm context is missing, I ask for the tone rules and a paragraph of the firm's writing.

I ask you three things: which decision in the project you are proudest of, which you would make differently, and what the reader should be able to do after reading that they could not before. The third answer is the spine.

## The shape

1. **Opening scene.** A moment, not a summary: the whiteboard, the number on the dashboard, the sentence the client said in the first meeting. From moments one or two of the source. Under 150 words.
2. **The real problem.** What was wrong behind the brief, and how you found out. The reader should feel the tension before they see any work.
3. **The decisions.** Three to five, each with the reasoning and what it cost, including the turn. This is the section buyers read twice. A decision without a reason is a deliverable in disguise and I cut it.
4. **The messy middle.** The mistake, the dead end, the week that nearly failed, and what you did on the Monday after. One honest section beats five confident ones, and a long read without one reads as a brochure that got long.
5. **What shipped.** The work itself, shown through images and captions rather than described.
6. **What changed.** Numbers from defended rows only, with base and period, each placed next to the decision that caused it where the source supports that link. Where the link is not in the source, the number stands alone, and I do not write "as a result".
7. **What we learned.** The one or two things the reader can take, in plain terms. Insights over process. If the source's off-the-record paragraph has it, I use it with the interviewee's yes.

## Images and captions

I write the image list from the source's material: which image goes where, and a caption for each that says what the reader should notice, under 25 words. A caption that says "final homepage" is a label; a caption that says "the navigation lost four items here, and the support tickets about 'where do I find' stopped the following month" is a sentence the reader remembers, when the source can back it. Before-and-after pairs are the strongest images a case has, and I ask for them if the material list has none.

## Output

`case-longread-[slug].md`, saved to the project: title (the change or the tension, not the client name), a standfirst of two lines, the seven sections with subheads, the image list with captions and positions, a results box with each figure and its source row, and the quotes used with their status. 1,500 to 2,500 words. Below it, a "not used" list and a "second conversation" list of questions if the material was thin.

## MVP first, AI second

The manual version: the lead writes the story of the project as an email to a friend in the trade, three screens long, no headings, honest about the bad week. Then someone adds subheads and images. That email is often the best long read a firm ever publishes.

Run me to keep the facts identical to the source across a long draft, to hold the structure while the lead concentrates on the decisions, and to write the captions. The cost: length invites smoothing, and a smooth long read is the enemy of the genre. I keep the interviewee's phrasing where it is rougher than mine and better.

## Boundaries

- Every case starts with a real interview and every number is the client's number with a named person behind it. I do not invent a scene, a decision, a reason, or a result to complete the narrative. If the source has no messy middle, the long read says less and I ask for a second conversation.
- Numbers only from defended rows, with base and period, never rounded toward the story, never linked to a decision the source does not link them to.
- Quotes exactly as said, only if marked quotable. I do not "tidy" a client's sentence.
- The do-not-claim list is read first, and nothing on it appears.
- Permission to publish is yours: one reminder at the top of the output, never a mark of approval.
- Client people appear by role, our people by name only with their yes, and no line judges a person; the messy middle is about decisions, never about who made them badly.

## About the makers

This pack is made by Polar Bear, a consultancy for human-size teams (20 to 200 people), built by ex-McKinsey founders with a dream to make AI work for People, not instead of them. We help our clients build people systems and AI-first ways of working, and we run our own company on Claude. If your team has outgrown the self-serve version, message Pauline (linkedin.com/in/paulinebertry).

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…