Skills
skills/timescale/marketing-skills/case-study-publisher

case-study-publisher

Installation
SKILL.md

Case Study Publisher

This skill orchestrates the Tiger Data case study publishing workflow. It uses a single intake form as the source of truth and executes the selected steps, pausing for your explicit approval before any action that sends a message, submits a form, or publishes content.

Step 0: Pre-flight check

Read REFERENCES.md from the plugin root and run the pre-flight check described there. Call list_marketing_references() to verify Tiger Den is reachable. If it fails or the tool is not found, STOP — do not continue. Follow the error handling in REFERENCES.md.

Also fetch the No Fly List before doing any work:

get_marketing_reference(slug: "no-fly-list")

This is a list of customers who cannot be publicly referenced. If the customer in the intake form 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 source material you are working from, omit it from all outputs.

Step 0b — Confirm which steps to run

Ask this before showing the intake form. Not every publication needs all 6 steps — AWS Portal and swag are commonly skipped, and sometimes social posts aren't needed either.

Which publishing steps do you need for this case study?

  1. Customer Social Proof Spreadsheet
  2. Google Slides case study slide
  3. LinkedIn post draft
  4. X (Twitter) post draft
  5. AWS Partner Portal submission
  6. Swag order form

Reply with the step numbers you want (e.g. "1, 2, 3, 4"), say "all" for all 6, or say "skip 5" / "skip 5 and 6" to exclude specific steps.

Wait for the reply. Store the selected steps. Only execute selected steps — skip all others silently and mark them as "⏭️ Skipped (not selected)" in the final summary.

Intake form scoping: Only ask the user to fill in sections relevant to their selected steps:

  • Steps 3 & 4 not selected → omit Section 9 (Social Post Preferences)
  • Step 5 not selected → omit Section 8 (AWS Partner Portal fields)
  • Step 6 not selected → omit Section 10 (Swag Order Details)

How to start

If the user hasn't filled in an intake form yet

After confirming which steps to run (Step 0b above), output the relevant sections of assets/intake-template.md — omitting any sections for skipped steps as noted above. Tell the user:

Here's your intake form. Fill in every field, then paste it back here and I'll run the selected steps.

Then wait. Don't proceed until the user returns with a completed form.

If the user has already filled in an intake form

Parse it immediately. Extract every field into a mental data model you'll reference throughout all selected steps. Then begin the first selected step.

The workflow

Work through selected steps in order (1 → 6, skipping unselected ones). For every step that involves an external action (clicking Submit, posting to Slack, sending a DM, clicking Save), you must:

  1. Show exactly what you're about to do and what content will be submitted/sent
  2. Ask: "Ready for me to [action]? (yes / no / edit)"
  3. Wait for an affirmative before proceeding
  4. If the user says "edit" or makes corrections, apply them and re-show before re-asking

Step 1 — Customer Social Proof Spreadsheet

What this step does: Opens the Tiger Data Customer Social Proof Google Sheet and adds or updates a row for the new customer.

Reference config: See case-study-publisher-config in Tiger Den → "Step 1: Customer Spreadsheet"

Execution

  1. Open the spreadsheet URL from config in the browser

  2. Find the correct tab (usually the current year or "All Customers")

  3. Navigate to the first empty row

  4. Map intake form fields to spreadsheet columns using the column mapping in config

  5. Show the user a preview of the row you're about to add. Only include the 11 columns defined in config — no extras. Leave any unknown values blank rather than guessing:

    Ready to add this row to the spreadsheet?

    Column Value
    Customer [value]
    Reference Date [value]
    Industry [value]
    Company Size [value]
    Use Case Type [value]
    Migrated From [value or blank]
    Business Use Case [value]
    Stats [value]
    Pull Quote [[quote one]] [[quote two]] …
    Link to Full Case Study [value]
    Video [value or blank]
    Ready? (yes / no / edit)

  6. After confirmation, enter the values cell by cell using form_input or javascript_tool

  7. Save (Cmd+S or the Save button if present)

Step 2 — Google Slides Case Study Slide

What this step does: Adds a new slide to the Tiger Data Case Study slide deck using the intake form's Headline, Key Capability paragraph, Pull Quote, CTA link, and customer logo.

Reference config: See case-study-publisher-config in Tiger Den → "Step 2: Google Slides Deck"

Execution

  1. Open the deck URL from config

  2. Duplicate the most recent case study slide (to inherit the correct layout and formatting)

  3. Replace each text placeholder with intake data:

    • Left panel bold headline → Section 3 (Slide Headline)
    • Key capability body → Section 4 (Key Capability Paragraph)
    • Pull quote text and attribution → the slide quote chosen in Section 7
    • CTA button text → Section 5 (Slide CTA Link Text); update the hyperlink to Section 1's case study URL
    • Customer logo → if a URL was provided in Section 1, open it in a new tab and download/upload it into the slide

    Key Capability writing standard: The Key Capability paragraph must describe what the customer's product or service delivers to their end users — concrete business value in plain language, not a feature list or a description of Tiger Data's role. It should answer: "What does the customer now do for their customers, and why does that matter?"

    A strong paragraph names the mechanism (what the customer built), states the outcome the end user experiences, and is written from the customer's product perspective — not Tiger Data's. Tiger Data is infrastructure; the slide is about what the customer built on top of it.

    See the case-study-writing-examples reference doc in Tiger Den for real customer examples that meet this standard.

    If Section 4 of the intake already meets this standard, use it verbatim. If it reads as a feature description or puts Tiger Data in the subject position, rewrite it to match the pattern above before placing it on the slide.

  4. Preview the slide visually (take a screenshot)

  5. Show the screenshot and ask:

    Ready to save this slide? Screenshot above. Any changes before I save? (yes / no / edit)

  6. After confirmation, save the deck

Step 3 — LinkedIn Post Draft

What this step does: Drafts a LinkedIn post announcing the case study.

Social post tone guidelines (these are Tiger Data defaults — override with intake Section 9 preferences):

  • Focus on the customer problem solved, not Tiger Data's product features
  • Lead with a concrete outcome or metric
  • No geographic references (don't say "Spain-based" or "US company")
  • Tag the customer's LinkedIn company handle if Section 9 says yes, using @[handle]
  • Include hashtags from Section 9 (if none specified, use: #TimeSeries #TimescaleDB #CustomerStory)
  • Keep it under 700 characters for best reach
  • Apply WABL and no-slop rules from the brand voice guide

Execution

  1. Draft the post using intake data (stats from Section 6, quotes from Section 7, headline from Section 3)

  2. Show the draft in a code block:

    LinkedIn post draft — does this look good? [draft here] Approve to copy to clipboard / open LinkedIn, or say "edit" to revise.

  3. After approval, this step is draft-only — you don't post it automatically. Tell the user the post is ready and remind them to paste it into LinkedIn.

Step 4 — X (Twitter) Post Draft

What this step does: Drafts an X post (≤ 280 characters) for the same case study.

Same tone guidelines as LinkedIn, but compressed. Lead with the single strongest metric. Include the case study URL (Section 1). Use 1–2 hashtags max. Apply WABL and no-slop rules.

Execution

  1. Draft the post

  2. Show it and confirm character count is ≤ 280

  3. Ask for approval:

    X post draft ([N] chars): [draft here] Good to go? (yes / edit)

  4. After approval, draft-only — remind the user to post it manually.

Step 5 — AWS Partner Portal

What this step does: Fills in a new Case Study entry on AWS Partner Central using data from intake Sections 1–4, 6, and 8.

Reference config: See case-study-publisher-config in Tiger Den → "Step 5: AWS Partner Portal"

Execution

  1. Qualify the customer first — before opening the portal.

    Post this message to @tiger-analytics in #ask-tiger-analytics (channel ID: C0AKT13LYPN):

    Is [Company Name] a customer? Do they use AWS?

    Wait for the reply. Evaluate the response:

    • If the answer is No to either question (not a customer, or doesn't use AWS):

      ⚠️ Skipping Step 5 — @tiger-analytics confirmed that [Company Name] either is not a customer or does not use AWS. The AWS Partner Portal case study entry will not be created.

      Mark Step 5 as skipped in the final summary and move on to Step 6.

    • If the answer is Yes to both (confirmed customer AND uses AWS): proceed.

  2. Tell the user: "I'm about to open the AWS Partner Portal and fill in the case study form. You'll need to be logged in — let me know if you need a moment." Ask: "Ready to open the AWS form? (yes / no)"

  3. After confirmation, navigate to the portal URL from config

  4. Click "Add Case Study" (or equivalent CTA on the list page)

  5. Page 1 — Main Details: Fill these fields from intake data:

    Form field Intake source
    Case Study Title Section 8
    Case Study Short Description Section 8
    Industry Section 1 (Industry) → map to portal Industry Vertical picklist value in config
    Use Case Section 8 (Use Case checkbox)
    Country of Work Always include "United States" plus any additional countries named in intake Section 2 (Country of Work). Add all of them to the Chosen column.
    Problem Statement Section 8
    Proposed Solution & Architecture Section 8 (or reuse Section 4 if "same as section 4" is written)
    Outcomes / Success Metrics Section 8 (or reuse Section 6 if "same as section 6" is written)
    TCO Analysis Section 8
    Lessons Learned Section 8
    Public or Private Section 8
    Project Start Date Section 8
    Project End Date Section 8

    ⚠️ Date field warning: The Project Start Date and Project End Date fields may auto-populate with today's date. Always explicitly set both dates from intake Section 8, even if the fields appear pre-filled — they will likely be wrong.

    For dual-listbox picklists (Countries, Industries, Use Case): use JavaScript DOM manipulation to move options from the "Available" select to the "Chosen" select. See the JS pattern in case-study-publisher-config in Tiger Den → "AWS Portal: Dual-Listbox Pattern".

    Show a summary of all the values you've filled before clicking Save & Continue:

    Page 1 filled. Ready to click Save & Continue? [table of field → value] (yes / no / edit)

  6. Page 2 — Services & Programs:

    • Add ISV Accelerate to the Related Programs Chosen column (always, regardless of intake)
    • Add any AWS services from Section 2 (AWS Services Used) to the AWS Services picklist. Use the exact option names available in the portal — if an expected service isn't present, pick the closest match and note the substitution for the user.
    • Add relevant Related Competencies based on the customer's industry/use case. See the competency mapping table in case-study-publisher-config in Tiger Den → "AWS Portal: Related Competencies".
    • After adding each item, scroll to the Chosen column to verify it actually appears there. The add operation can silently fail. If an item is missing, add it again before continuing.
    • Show a summary of everything added and ask: "Ready to save page 2? (yes / no)"

  7. Page 3 — Attachments:

    • The architectural diagram must be uploaded manually — you cannot automate file uploads from your conversation context. Scroll to the "Reference / architectural diagram" file input and instruct the user: "Please click Choose File and upload the architectural diagram now."
    • Wait for the user to confirm they've uploaded it before proceeding.
    • Click Save & Continue (with permission as usual).

  8. Confirmation page: Confirm the submission succeeded. Screenshot and tell the user.

Step 6 — Swag Order Form

What this step does: Fills in the Tiger Data Swag Request Google Form with customer and order details from the intake form, then submits it after your approval.

Reference config: See case-study-publisher-config in Tiger Den → "Step 6: Swag Order"

Execution

  1. Resolve the mailing address:

    • Check intake Section 10: "Use company HQ address or personal shipping address?"
    • If HQ: query @tiger-analytics in #ask-tiger-analytics: What is the company HQ address for [Company Name]?
      • If a complete street address is returned, use it.
      • If not found, pause and ask the user to provide it before continuing.
    • If Personal: use the address provided in Section 10.

  2. Open the form URL from config.

  3. Fill in the form fields using the mapping in config:

    Form field Source
    Date Today's date
    Account Name/Company Name Section 1: Customer / Company Name
    Contact's Full Name Section 1: Customer Contact Name
    Contact's E-mail Section 1: Customer Contact Email
    Mailing Address Resolved in step 1 above
    Phone Number Section 10: Contact phone number (enter "NA" if not available)
    Swag Options Always select "Standard Kit" unless Section 10 explicitly specifies a different item
    T-shirt/Jacket Size (Unisex) Section 10: Customer t-shirt size

    Swag Options note: "Standard Kit" (T-shirt, Notebook, Pen, Water bottle, Stickers) is the default for all new case study customers. Only select a different option if the intake form explicitly calls for something else (e.g., a custom item for a named customer deal).

    T-shirt size dropdowns: The size picker in this form is a custom Google Forms dropdown (not a native <select>). To open it reliably, use the element ref system to click the dropdown container, then use find to locate the target size option by text and click its ref. Do not rely on screen coordinates — they shift unpredictably.

  4. Show a preview of all values before submitting. Always include the form URL in the preview message so the user can submit manually if the browser automation doesn't work:

    Ready to submit the Swag Request Form? Form URL: [from case-study-publisher-config in Tiger Den → Step 6: Swag Order → Form URL]

    Field Value
    Date [value]
    Account Name [value]
    … …
    Submit? (yes / no / edit)

  5. After approval, click Submit on the form.

  6. Confirm the "Your response has been recorded" confirmation page is shown. Screenshot and report success to the user.

After all steps complete

Provide a brief summary checklist, marking each step as completed, skipped, or needing follow-up:

✅ Step 1 — Spreadsheet row added
✅ Step 2 — Case study slide added to deck
✅ Step 3 — LinkedIn post drafted (ready to post manually)
✅ Step 4 — X post drafted (ready to post manually)
⏭️ Step 5 — Skipped (not selected)
⏭️ Step 6 — Skipped (not selected)

Flag any steps that need follow-up (e.g., "Architectural diagram — please upload manually to the AWS Portal before the submission can be reviewed").

Error handling

  • Spreadsheet column not found: Ask the user to point you to the correct column header before proceeding.
  • AWS form field missing from intake: Skip the field if optional; ask the user if required.
  • #ask-tiger-analytics says customer is not on AWS or not a customer: Skip Step 5 entirely — do not open the portal. Note it in the final summary.
  • Swag form won't load: Give the user the form URL and the filled values so they can submit manually.
  • Logo URL broken or missing: Skip the logo on the slide and note it in the summary.
  • Address not found in #ask-tiger-analytics: Pause and ask the user to provide the shipping address before filling the form.
  • Phone number missing from intake: Enter "NA" in the Phone Number field — do not block the workflow or ask the user for it.
  • Browser tab session lost after user logs in (AWS or Google): After the user completes a manual login, the active tab context may change. Call tabs_context_mcp to get the current tab list, identify the correct tab by title or URL, and navigate back to the target page before continuing.
  • AWS portal item silently not added to Chosen list: After adding a service, program, or competency, scroll the Chosen column to verify the item appears. If missing, add it again. This is a known portal quirk — do not assume success without visual confirmation.
  • Google Slides text replacement unreliable: Use Find & Replace (Cmd+Shift+H / Ctrl+Shift+H) with form_input targeting the input ref IDs. Do not rely on clicking slide elements directly by coordinate — grouped elements in Google Slides are not reliably click-targetable. Use Tab key cycling only as a last resort if Find & Replace is unavailable.
Weekly Installs
1
Repository
timescale/marke…g-skills
GitHub Stars
5
First Seen
Apr 13, 2026
Security Audits
Gen Agent Trust HubPass
SocketPass
SnykPass