# Case Study Builder

> Turn evidence about one customer, client, project, or outcome into a credible case study, success story, proof page, sales story, or short proof block.

- Skill: `nahiddotai/case-study-builder` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add nahiddotai/case-study-builder`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nahiddotai/case-study-builder/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: nahiddotai (https://skillmd.com/u/nahiddotai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nahiddotai/case-study-builder

---


# Case Study Builder

Turn one real outcome into trustworthy proof without upgrading partial evidence into a miracle story.

## Job contract

- Owns: a publishable story about one customer or project.
- Does not own: cross-customer patterns (`customer-insight-synthesizer`) or a general meeting analysis (`meeting-miner`).
- Finished deliverable: a case study, clearly labelled project story, or evidence plan, plus a claim ledger and approval checklist where relevant.

## Evidence gate

Classify the evidence before drafting:

- `Full case study`: the starting situation, intervention, and meaningful outcome are all supported by traceable evidence. Proceed with the requested case-study format.
- `Project story`: the work and process are supported, but the customer or business outcome is not. Produce a useful project story and state plainly that no outcome claim is being made.
- `Evidence plan`: the work, change, or outcome cannot yet be verified. Do not manufacture a narrative. Return the missing evidence and the smallest practical plan for collecting it.

Quotes, metrics, customer names, logos, and claims of approval remain blocked until their source or permission is verified.

## Workflow

1. Inventory the customer, starting situation, stakes, constraints, intervention, timeline, outcome, sources, permissions, and confidentiality needs.
2. Separate verified facts, customer statements, user interpretation, and missing evidence.
3. Run the evidence gate and tell the user which route the material supports.
4. Find the real change. Prefer a specific credible result over an inflated transformation.
5. Build the narrative: situation, tension, decision, work, result, meaning.
6. Attribute quotes and numbers. Mark anything requiring customer approval.
7. Produce the supported format: proof block, one-page story, sales-page section, full case study, project story, or evidence plan.

## Output

```markdown
# [Outcome-led title]

## At A Glance
[Customer, challenge, work, result]

## The Starting Point
[Specific context]

## What Changed
[Actions and mechanism]

## The Result
[Verified outcomes and limits]

## Why It Mattered
[Customer consequence]

## Claim Ledger
| Claim | Source | Status | Approval needed |

## Publication Checklist
[Name, logo, quote, metric, confidentiality approvals]
```

## Guardrails

- Never invent or round up results, dates, quotes, titles, logos, or customer approval.
- An internal draft is not permission to publish.
- Anonymise only when requested and ensure the remaining detail cannot re-identify the customer.

