Skip to content
Beta Multi-model support (OpenAI, Gemini, and more) launching soon.
RBA RBA Skills

case-study-draft

Installable Ships in case-study-writer — or copy the raw skill below.
Open Claude.ai

Paste into Claude Code, Claude.ai, the desktop app, or the browser extension — ⌘/Ctrl+V.

ExperimentalNo security review

Case Study Draft

Produce a polished, client-facing case study from project artifacts and metrics. The output follows RBA's Challenge → Approach → Impact → CTA narrative arc and is calibrated to the specified audience and format.

A great RBA case study is the most powerful sales tool BD and marketing have. It is specific (real numbers, named outcomes — never vague claims), results-driven (lead with impact, not with RBA's capabilities), and collaborative in tone (RBA worked with the client, not for them). It tells a story; it must never read like a brochure.

Brand output: all formatting, typography, colour, and per-format layout rules come from resources/rba-design-system.md (see § Case Studies and § One-Pagers there) — cite it for every branded asset rather than inventing visual treatment here.

Brand voice rules (enforced throughout): Confident but not arrogant. Direct and plainspoken. Specific numbers over vague claims. Explain the why. Use "RBA" — never "our team." Never use these banned words: world-class, cutting-edge, synergy, leverage, seamless, robust, holistic, operationalize. The canonical voice source is the standalone rba-brand-voice skill — apply it for the full pillar/vocabulary/grammar standard, and treat the rules here as its short summary.

When this skill applies

  • Project has closed or entered hypercare and a case study is needed
  • BD or strategy lead has a brief, retrospective, or set of project notes ready
  • Metrics have been gathered (or metrics-collector was run first)
  • Client approval status is known (use --approved flag only when written approval exists)

Skip for: internal-only win story → win-story-brief; award nomination → award-submission-writer; partner tier evidence → partner-evidence-package.

Inputs

Parameter Required Default Notes
brief-file-or-description Yes — File path to brief, retro, SOW, or inline description
--client No inferred Client name for the output; omit to use anonymised version
--platform No auto-detect Platform adapter(s) for proof-point framing
--format No both web = long-form narrative; one-pager = condensed PDF layout
--audience No prospect Calibrates evidence depth and tone
--approved No false Flag when client has given written approval to publish

Workflow

Step 1 — Ingest and gap-check

Read all provided files. Extract:

  • Client sector and organisation size — shapes the peer-comparison relevance for prospects
  • Engagement scope — platforms, integrations, team size, duration
  • Stated business problem — the challenge in the client's own words if available
  • Delivered capabilities — what RBA built, migrated, or configured
  • Metrics present — conversions, page speed, editor velocity, cost reduction, project delivery stats

If core metrics are missing, pause and prompt:

Key metrics are missing. To write a compelling results section, I need at least 2–3 of:
- Performance: page load time before/after, Core Web Vitals scores
- Engagement: session duration, bounce rate, conversion rate delta
- Editorial: time-to-publish before/after, content author satisfaction
- Business: leads generated, revenue influenced, support-ticket reduction
- Delivery: timeline vs. estimate, defect escape rate, sprint velocity

Please supply at least two metrics, or run metrics-collector first.

Do not fabricate or round up metrics. If the client has not approved specific numbers, replace them with directional language (e.g., "significant reduction in page-load time") and note the gap in the drafting notes.

Step 2 — Platform adapter selection

Apply the platform-specific proof-point framing from reference.md § Platform Adapters. Key points:

  • Sitecore XM Cloud: composable migration, SaaS hosting cost delta, XM Cloud personalisation, Content Hub editorial consolidation, headless Next.js/Astro frontend decoupling
  • Optimizely CMS / One: experiment velocity, personalisation uplift %, editorial publishing speed, Optimizely One SaaS consolidation, Feature Experimentation SDK integration
  • Umbraco: open-source migration savings vs. prior licence costs, developer experience, headless Delivery API adoption, Umbraco Cloud DevOps
  • Azure / Microsoft 365: infrastructure TCO reduction, DevOps pipeline maturity score, Azure OpenAI/Copilot integration outcomes, Entra ID SSO rollout
  • Composable / headless (no single vendor): MACH milestones, number of integrated services, time-to-content improvement, frontend framework choice rationale

For multi-platform engagements: lead with the business outcome; mention each platform by name in the Approach section without over-indexing on vendor marketing language.

Step 3 — Draft structure

Produce the case study in the order below. See templates.md for copy-paste-ready section starters. See examples.md for annotated RBA-style examples.

Header block

Client:        [Name or "Global Financial Services Firm" if unapproved]
Sector:        [e.g. Financial Services | Healthcare | Retail | Manufacturing]
Platform(s):   [e.g. Sitecore XM Cloud + Azure]
Engagement:    [e.g. DXP Migration + Personalisation Programme]
Duration:      [e.g. 8 months]
Team size:     [e.g. 12 (RBA) + 4 (client digital team)]

Headline

One sentence. Lead with the outcome, not the technology. Pattern: [Client/sector] [reduced/achieved/transformed] [outcome] by [metric] [timeframe context].

Good: "A global insurance group cut content-publishing time by 65% after migrating to Sitecore XM Cloud." Avoid: "RBA implemented Sitecore XM Cloud for a global insurance group."

Overview (1–2 short paragraphs)

A tight executive summary: what the client needed to solve and what RBA did. End on a single sentence that frames the result. This is the hook that earns the rest of the read.

Challenge (150–250 words)

  • Open with the business pressure the client faced — not the technical debt. The first paragraph is about the client's problem, never about RBA's capabilities.
  • Describe the legacy situation in concrete terms: system, age, cost, friction
  • Include a pull quote that captures the core tension. Use the "The biggest surprise wasn't X — it was Y" pattern to surface the most counter-intuitive thing about the engagement. Example: "The biggest surprise wasn't the CMP licensing — it was how much unseen work sat between the vendor's 'implementation' and actually getting every tag to respect consent."
  • Include a client quote (verbatim if approved; paraphrased to "[Client stakeholder]" if not)
  • End with the stakes: what was the cost of inaction?

Approach (250–400 words)

  • Introduce as "RBA's approach to [topic]," then lead with the strategic framing — what differentiated the solution choice
  • Present the work as 3 numbered phases (each with a name + 1–2 paragraphs on what RBA did, why the step mattered, and what was discovered). Walk through them in plain language, not sprint labels.
  • RBA partnered with internal teams ("RBA partnered with internal teams to provide patterns and guidance") — not "RBA implemented everything for them."
  • Call out notable technical decisions and why they were made
  • Highlight RBA team capabilities: disciplines involved, certifications relevant, methodology
  • Platform-specific proof points from Step 2

Phase structure (the canonical 3-phase shape; add a 4th only if genuinely warranted):

### Phase 1 — [Name]
### Phase 2 — [Name]
### Phase 3 — [Name]

For the one-pager/PDF, note the process diagram for the designer: `[LAYOUT NOTE: 3-step horizontal flow — icons, aqua numbered badges, connecting arrows, step label

  • bullet activities below each step](visual spec lives inresources/rba-design-system.md`).

Impact (150–250 words)

  • Open with the headline metric
  • Frame impact as what the client can now do that they couldn't before — measurable change
  • Use a 3–5 item bulleted register for the metrics (see templates.md § Results bullets). Every claim needs either a specific number or a named outcome: "$400K+ cost avoidance" not "significant savings"; "94% reduction" not "dramatically reduced."
  • Use bold emphasis on key phrases within paragraphs
  • Include a client testimonial quote (attributed if approved; paraphrased if not)
  • Close with the forward-looking opportunity or ongoing engagement

Reflections (1–2 paragraphs)

Strategic takeaway — what this engagement reveals about the broader challenge organisations face. This is thought leadership, not a pitch: it should make the reader think "this applies to us too," not "I should hire RBA." Omit on the condensed one-pager if space is tight.

CTA block — Request an RBA Briefing

Close the long-form case study with a call to action:

Headline:    Ready to [action tied to the outcome]?
Sub-heading: Request an RBA Briefing
Body:        2–3 sentences on what the briefing covers.
Button:      Request a Briefing
The Three T's:
  Topic — chosen based on your goals
  Time  — 60–120 minute session
  Team  — curated RBA strategists for your topic

See templates.md § CTA block for copy-paste-ready wording.

About RBA (boilerplate — 60 words max)

Standard RBA capability statement. See templates.md § About RBA.

Footer: Copyright © [Year] RBA, Inc. All Rights Reserved.

Step 4 — One-pager condensation (when --format one-pager or both)

Produce a condensed version for PDF layout:

Section Word target
Headline 10–15 words
Challenge (sidebar) 60–80 words
Approach (sidebar) 80–120 words
Results (callout boxes) 3 stats + 1 quote
About RBA 40 words

Annotate each section with [LAYOUT NOTE: ...] for the designer.

Step 5 — Approval and sensitivity check

Before returning the draft, verify:

  • No client-confidential financial figures unless --approved flag is set
  • Metrics cited are consistent with supplied inputs — no rounding that changes meaning
  • Client name used only if --approved or user explicitly confirmed it is public
  • No RBA internal pricing, margin, or cost-of-delivery figures included
  • No individual employee names from the client side without written consent
  • Platform vendor names are accurate (e.g. "Sitecore XM Cloud" not "Sitecore Cloud")
  • Technology acronyms spelled out on first use

Flag any gaps with inline [DRAFT NOTE: ...] markers so the BD reviewer knows what to resolve.

Step 6 — Output

Deliver:

  1. Long-form web case study (if --format web or both) — clean Markdown, ready for CMS
  2. One-pager (if --format one-pager or both) — annotated Markdown with layout notes
  3. Drafting notes — bullet list of assumptions made, gaps flagged, approval items outstanding

Remind the user to run case-study-reviewer before client sharing or publishing.

Reference and template files

  • reference.md — Platform adapter proof-point library, sector headline patterns, metric benchmarks
  • templates.md — Section-by-section starter copy, results bullet patterns, About RBA boilerplate
  • examples.md — Annotated examples of strong vs. weak challenge/approach/results writing
Technical details
Plugin
case-study-writer
Author
Dakota Smith
Skill name
case-study-draft
Maturity
experimental
Security review
No security review
Owners
  • business-development
  • strategy
Argument hint
<brief-file-or-description> [--client <name>] [--platform sitecore|optimizely|umbraco|azure|composable|headless] [--format web|one-pager|both] [--audience prospect|partner|internal] [--approved]
Allowed tools
  • Read
  • Write
  • Edit
  • Bash(find *)
  • Bash(ls *)
  • Bash(grep *)
Source
plugins/case-study-writer/skills/case-study-draft/SKILL.md

Edit this skill on GitHub — opens GitHub's web editor. No git knowledge needed.