Produce a complete, publication-ready Tiger Data customer case study (.docx) from a customer interview transcript. Generates an embedded architecture diagram, writes WABL-compliant copy in the Tiger Data Community Member Spotlight format, and produces a 5-quote pull quote table for editorial and social use. MANDATORY TRIGGERS: write a case study, draft a case study, build a case study, turn this interview into a case study, create a case study from this transcript, case study from interview, write up this customer story, draft customer story, write this up as a case study, customer spotlight, community member spotlight. Also trigger when the user shares a transcript or interview doc alongside example case study copy and asks to produce written content from it. If the user says 'use the case study prep doc and transcript', this skill should run.
Produce a complete, publication-ready Tiger Data customer case study (.docx) from a customer interview transcript. Generates an embedded architecture diagram, writes WABL-compliant copy in the Tiger Data Community Member Spotlight format, and produces a 5-quote pull quote table for editorial and social use. MANDATORY TRIGGERS: write a case study, draft a case study, build a case study, turn this interview into a case study, create a case study from this transcript, case study from interview, write up this customer story, draft customer story, write this up as a case study, customer spotlight, community member spotlight. Also trigger when the user shares a transcript or interview doc alongside example case study copy and asks to produce written content from it. If the user says 'use the case study prep doc and transcript', this skill should run.
Case Study Builder
Produces a Tiger Data "Community Member Spotlight" case study from a customer interview
transcript. The output is a formatted .docx file with an embedded architecture diagram
and a pull quote table.
Before You Start: Read Two Reference Files
Read both of these before writing a single word of the case study:
references/wabl-principles.md — Tiger Data writing standards. Every sentence must
pass the WABL filter before the document ships.
references/case-study-format.md — The section structure, styling constants, and
annotated guidance for each section of the document.
Also read the docx skill (find the docx SKILL.md in your available skills)
before generating the .docx. The docx skill contains the exact docx-js patterns required
to produce a valid Word document.
Step 0: No Fly List check
Fetch the No Fly List before doing any work. This requires Tiger Den:
get_marketing_reference(slug: "no-fly-list")
If Tiger Den is not available (get_marketing_reference fails or the tool is not found), warn the user: "No Fly List check skipped — Tiger Den is not connected. Verify manually that no restricted customers are referenced in the output before publishing." Then proceed.
If Tiger Den is available, load the returned names as a hard constraint: if the customer featured in this case study appears on the No Fly List, stop immediately and inform the user that this customer cannot be publicly referenced. If a No Fly List name appears in the transcript or other source materials, omit it from all outputs.
Step 1: Gather Inputs
Collect the following from the user's message and conversation history:
Input
How to get it
Transcript (required)
Google Doc URL → google_drive_fetch; uploaded file → read from /mnt/uploads/; pasted text → use directly
Case Study Prep doc (optional)
Google Doc URL → google_drive_fetch. Contains pre-mapped answers to the 8 Tiger Data case study questions. Treat it as additional context — it does not replace the transcript.
Example case studies (optional)
If the user pasted example copy into the conversation, use it as the stylistic reference. Otherwise, follow the structure in references/case-study-format.md.
If the transcript is missing, ask for it before proceeding. Everything else is optional.
Step 2: Ask Two Clarifying Questions
Ask both at once. Do not start writing until you have answers.
Q1: First or third person?
The case study can be written as the customer speaking in first person ("I built this
because...") or as a third-person narrative ("Tacton's team built this because...").
The Tiger Data format supports both. First person is more personal and works well for
technical founders. Third person is easier to edit and suits larger orgs with PR teams.
Default to first person if the transcript is from a single technical founder.
Q2: Who is the primary reader?
Options: (a) developers and engineers — emphasise architecture, data model, technical
trade-offs; (b) technical buyers / VPs — emphasise ROI, team size, time-to-value;
(c) general — balance both. Default to (a) if the transcript is highly technical.
Step 3: Extract from the Transcript
Read the full transcript carefully. Extract and organise the following before writing:
Company basics
Company name, spokesperson name and title
Industry, customer type, company size
Product(s) being discussed
The problem
What was painful or broken before Tiger Data?
What did the old stack look like?
Why was the old approach unsustainable?
Why Tiger Data
How did they discover Tiger Data? (blog post, Reddit, colleague, etc.)
What alternatives did they consider?
What made Tiger Data the right choice? (specific criteria)
What would self-hosting have cost them?
Architecture
What are the named services, edge devices, brokers, APIs?
What data flows where? In what order?
What does Tiger Data specifically store? (data types, cadence)
What other databases or platforms are in the stack, and what do they hold?
How does data reach the customer-facing application?
Customer impact stories: specific incidents, prevented failures, ROI moments
Support / onboarding experience
Looking ahead
Roadmap items the customer mentioned
Scale targets, new data streams, future features
Direct quotes
Collect every quote that is punchy, specific, and quotable. Prefer quotes that are
concrete ("we went from 4 minutes to half a second") over abstract ("it's been great").
Note the exact words. You will clean up false starts and filler words but must not
change the meaning or put words in the customer's mouth.
Capture the context, not just the quote. Read the lines before and after each
quote. A quote can be word-accurate but context-wrong — if the customer said something
to explain why a problem is inherently complex (not to describe a failure of the old
stack), framing it as a pre-Tiger Data symptom is a misrepresentation. Note what the
speaker was responding to when they said it.
Step 4: Generate the Architecture Diagram
Write a Python script using matplotlib to produce the architecture diagram. Save it as
a PNG in the current working directory as architecture.png.
Design guidance is in references/architecture-diagram-guide.md. The short version:
White background, dot grid, monospace uppercase labels — no coloured zone fills
Draw boxes with FancyBboxPatch: bold label only, no body text, compact height (~0.68 units)
Tiger Data gets an orange border (2.5 lw), embedded logo badge, and a bold summary line
Arrows with ax.annotate: omit labels unless the protocol is non-obvious
Column headers as bold monospace text above each group
figsize=(8, 4.5), coordinate system 0–16 × 0–9, save at 180 dpi
Run the script and confirm the PNG exists before moving to the next step.
Step 5: Write the Case Study .docx
Writing directive: Rewrite in the first person voice of the customer primarily
pulling direct language from the transcript. Incorporate the Product Marketing Context
from Tiger Den into the narrative.
Follow the structure in references/case-study-format.md exactly. Use the docx skill
patterns for all formatting — never raw unicode bullets, never inline \n, and always
set explicit page size (US Letter: 12240 x 15840 DXA).
About the Company & Team
Lead with the customer problem — what pain does the end user of this product experience,
and why does it go unsolved today? Then explain how the product solves it, with specific
technical mechanisms. Team/founding story goes last and should be brief (1-2 sentences).
This section should read like a problem brief for a developer audience, not a company bio.
The Challenge
Describe the state of the world before Tiger Data. Be specific about what was slow, what
cost too much, what was operationally painful. If there was a prior stack (InfluxDB,
MongoDB, a Postgres cluster they self-hosted), name it and explain why it didn't scale.
Architecture-First Decision / Why Tiger Data
Explain how the customer found Tiger Data, what alternatives they considered, what the
specific decision criteria were, and why they chose managed over self-hosted. Include
the discovery story if it's interesting (a Reddit comment, a blog post from 2018,
a colleague recommendation). This is often the most differentiated section — it shows
the customer made a deliberate technical choice, not just the default one.
The [Product] Stack (architecture section)
Describe the full data flow in prose, naming every service. Then embed the architecture
diagram. Follow the diagram with a caption. Do not just list components — explain what
each one does and why it sits where it sits.
Results
Lead with the most impressive metric. Then tell the impact stories from the transcript
in order of emotional weight. Include at least one concrete before/after story
(e.g. "$3K fix prevented $350K in downtime"). Put a pull quote block after any section
where you have a strong direct quote that reinforces the message.
Looking Ahead
Forward-looking only. No summary of what was just said. One or two paragraphs about
what the customer plans to build next and how Tiger Data enables it.
Recommended Pull Quotes
A table at the end. 5 rows. Columns: the quote itself (attributed, with " - Name, Title,
Company"), and a recommended use note (hero, social, support section, etc.).
All quotes must be direct quotes from the transcript, lightly cleaned for readability.
Step 6: WABL Review Pass
Before finalising, run the WABL filter from references/wabl-principles.md:
Remove all em dashes. Replace with a regular hyphen-space ( - ) or restructure the sentence.
Scan for AI slop: "seamlessly", "robust", "cutting-edge", "transformative",
"game-changing", "leverage", "harness the power of", "it's worth noting", "delve into"
Confirm there is one clear message. If someone asks "what is this case study saying?"
the answer should be one sentence.
Confirm the About section does not start with the spokesperson's name and job title.
It should start with the customer's problem.
Confirm there is no recap conclusion. The Looking Ahead section should look forward,
not summarise what was said.
Read one paragraph aloud. Does it sound like a confident engineer who built this?
If not, rewrite it.
Step 7: Validate and Deliver
Run the docx validation script from the docx skill against the output file:
All validations must pass before delivering. If they fail, unpack the XML, fix the issue,
and repack using the docx skill's repair workflow.
Save the final file to the workspace/outputs directory and provide the user with a
computer:// link.
Common Mistakes to Avoid
Starting the About section with the spokesperson. "I'm [Name], CTO of [Company]..."
is a company bio opener. The reader does not yet know why they should care. Lead with the
problem the customer faces, then introduce the product, then briefly note who built it.
Paraphrasing quotes instead of using them. If the transcript has "we went from nothing
to first devices being installed in two months," use that. Don't write "they achieved
rapid deployment." Direct quotes are the whole point of a case study.
Making up metrics. Only use numbers that appear explicitly in the transcript or prep
doc. If a metric is approximate, say so ("close to 100 devices"). Never round up.
Skipping the discovery story. How the customer found Tiger Data is often the most
interesting paragraph in the piece. A Reddit comment that led to a 2018 blog post that led
to an architectural decision is a better story than "they evaluated several options."
Describing the architecture as a list. "We use X, Y, and Z" is forgettable. "X
captures sensor readings and sends them to Y via MQTT. Y validates the device, applies
calibration thresholds, and writes time-series data to Z" gives the reader a mental model
they will actually remember.
Using a quote accurately but in the wrong frame. If the customer said "it'll never
be a snap of the fingers" to explain why dashboard performance is inherently hard to
optimise — not to describe a failure of the old stack — attributing it as evidence of
pre-Tiger Data slowness is a misrepresentation even though the words are exact. Always
check what question the speaker was answering when they said it.
Writing a generic Looking Ahead close. "Ready to expand their business at scale"
says nothing. If the case study is about an architectural decision (single database,
no split stack), the Looking Ahead section should land on what that decision means as
the product scales — the specific complexity or cost problem that won't arise.
