Tiger In The Wild Research

TimescaleDB Marketing Stories in the Wild — Monthly Research Skill

Purpose

Find NEW organic third-party blog posts and user stories about our products published since the last scan. Append them to the master results file and flag what's new. Do not re-report previously found content.

Note: output/ and state/ are gitignored — they contain company names,

competitive context, and candidate rankings that cannot live in a public repo.

These directories are created locally on first run and remain on your machine only.

When this skill runs

• Trigger: /tiger-in-the-wild or natural language like "find new user stories",

"update tiger-in-the-wild research", "run the monthly in-the-wild scan"

• Schedule: First Monday of each month (when scheduled via Cowork)
• Runtime expectation: 10–20 web searches, 5–10 page fetches.

This is a heavyweight research skill — not for repeated daily use.

Step 1 — Load state from last run

1. Read state/last-run.md. It contains the date of the last scan and a list of all previously found URLs. 2. Read output/in-the-wild-master.md. This is the cumulative master file. 3. If state/last-run.md does not exist, treat this as the first run and search with no date constraint. 4. Set SEARCH_AFTER to the date in last-run.md (e.g., 2026-03-28). 5. User override: If the user specifies a custom time range (e.g., "search the last 6 months", "go back to January"), use that date instead of SEARCH_AFTER from state. Still use the known URL list from state for deduplication — only the date window changes.

Step 2 — Search for new content

Run web searches using the queries below. Append the current year to date-sensitive queries. Restrict results to content published AFTER SEARCH_AFTER.

Search queries (run all of these)

TimescaleDB blog experience {current_year}
TimescaleDB blog experience {current_year - 1}
"Tiger Data" OR "Tiger Cloud" blog review experience
"TimescaleDB" site:medium.com {current_year}
"TimescaleDB" site:dev.to {current_year}
"TimescaleDB" site:substack.com
"why we chose TimescaleDB" blog
"migrated to TimescaleDB" blog {current_year}
"TimescaleDB" engineering blog
TimescaleDB review OR testimonial {current_year}
"TimescaleDB MST" OR "Managed Service for TimescaleDB" Aiven blog
"TimescaleDB" site:hashnode.dev {current_year}
site:news.ycombinator.com "timescaledb"
"TimescaleDB" site:github.com README
"TimescaleDB" site:speakerdeck.com
"TimescaleDB" site:youtube.com conference OR talk OR presentation
TimescaleDB ブログ 経験 {current_year}
TimescaleDB Erfahrung Blog {current_year}

For each search result

• Skip if the URL is already in state/last-run.md (known URL list)
• Skip if hosted on an EXCLUDED domain (see below)
• Fetch and read the page to confirm it is genuine user-authored content
• Skip if it is product documentation, a changelog, or marketing copy

written by the product company itself

Step 3 — Cross-reference tigerdata.com

Before including any company, check whether they are already featured:

1. Fetch https://www.tigerdata.com/case-studies and extract all company names and blog post URLs listed there. 2. Fetch https://www.tigerdata.com/blog (first page) and scan for any matching company names. 3. If the company appears in either location, EXCLUDE it from results and note it in the "Already on tigerdata.com" section of the output.

Step 4 — Format new results

For each new entry found, format it using the exact template in references/entry-template.md.

Classify each entry as:

• Company — if the author writes on behalf of a named company

or on a company engineering blog

• Individual Developer — if the author is writing independently

on Medium, Dev.to, Substack, Hashnode, LinkedIn, personal blog, etc.

Company-level deduplication

Before creating a new entry, search the master file for the company name (case-insensitive). If a match is found, MERGE the new post into the existing entry rather than creating a duplicate — add the new link and summary under their heading and update the date range. Do not count merged posts as new entries in the summary count.

If an individual author already exists in the master file with earlier posts, apply the same merge logic.

Flag cautionary or negative posts with ⚠️ but still include them.

Tier classification (apply here, before writing output)

Assign a tier to each entry and add it as a Tier row in the entry table.

Tier 1 — strong case study candidate. Requires ALL of:

• Named company (not anonymous "a startup" or "my company")
• Production deployment with specific metrics (data volume, latency,

cost savings, compression ratios)

• Deep technical detail or explicit "why we chose" rationale with

alternatives named and evaluated

Tier 2 — notable signal. Meets 1–2 of the Tier 1 criteria but not all. Individual developers with strong production metrics can qualify.

Tier 3 — informational. Integration guide, tutorial, or post with no personal production experience or named company. Worth logging; not prioritized for outreach.

Step 5 — Write outputs

A. Incremental report → output/new-findings-{YYYY-MM}.md

Create a short report of ONLY what's new this month:

---
title: "In the Wild — New Findings {Month Year}"
scan_date: {today's date}
search_after: {SEARCH_AFTER date}
new_entries_found: {count}
---

# New findings since {SEARCH_AFTER}

{list of new entries in the standard format}

## Top 3 outreach candidates
{List up to 3 Tier 1 entries — author/company name, link, and one sentence on
why they're a strong candidate. If fewer than 3 Tier 1 entries were found,
fill with the strongest Tier 2 entries. If none qualify, write "None found this scan."}

## Already on tigerdata.com (excluded)
{any companies found that were filtered out}

## No new results from
{list any search queries that returned zero new hits}

B. Update master file → output/in-the-wild-master.md

• Insert new Company entries into the Companies section, maintaining

reverse chronological order, and renumber all entries.

• Insert new Individual Developer entries into the Individual Developers

section, maintaining reverse chronological order, and renumber.

• Update the YAML frontmatter updated: field to today's date.
• Update the Summary tier tables if any new entry qualifies for Tier 1

or Tier 2 (has named company, production metrics, or benchmarks).

C. Update state → state/last-run.md

Overwrite with:

last_scan_date: {today's date}
total_entries: {count of all entries in master file}
new_this_scan: {count of new entries found}

## Known URLs
{complete list of every URL in the master file, one per line}

Configuration

Products to search for

• TimescaleDB
• Tiger Data
• Tiger Cloud
• TimescaleDB MST (with Aiven)

Domains to EXCLUDE (never include content from these)

• tigerdata.com
• timescale.com
• docs.tigerdata.com
• docs.timescale.com
• forum.tigerdata.com

Platforms to prioritize

• Medium
• Dev.to
• Substack
• Hashnode
• LinkedIn Pulse / LinkedIn articles
• Hacker News (news.ycombinator.com)
• Reddit (r/PostgreSQL, r/dataengineering, r/selfhosted, r/devops)
• GitHub (README files, repo descriptions)
• Company engineering blogs (e.g., blog.cloudflare.com, engineering.*.com)
• Conference talk slides (SpeakerDeck, SlideShare)
• YouTube conference talks (QCon, PGConf, re:Invent, DataEngConf)
• Personal developer blogs (Blogspot, WordPress, Hashnode, personal domains)
• Non-English developer blogs (Japanese, German)

Entry quality bar

Include an entry if it meets ANY of these:

• Describes a real production deployment with specifics (data volume,

latency, compression ratios, cost savings)

• Explains a "why we chose" decision with named alternatives evaluated
• Documents a migration from another database to TimescaleDB
• Provides benchmarks or performance comparisons
• Shares operational lessons learned or troubleshooting stories
• Is a detailed technical integration guide using TimescaleDB

Do NOT include:

• Generic "what is TimescaleDB" explainer posts with no personal experience
• SEO listicles ("Top 10 time-series databases")
• Vendor comparison pages from competitors
• Content clearly written by AI with no original experience

<!-- Entry template for In the Wild skill. Copy this block for each new entry. Fill in all fields. Place under the correct section (Companies or Individual Developers). -->

{number}. {Company or Author Name}

Link: {Article title}

{2–4 sentence summary. Include specific metrics if available: compression ratios, latency improvements, data volumes, cost savings. Note which alternatives were evaluated or replaced. Mention any candid limitations or gotchas the author reported.}

<!-- Optional: Add this block only for Tier 1 candidates (named company + production metrics + deep technical detail) --> Why it's strong: {One sentence on why this is a standout entry.}

<!-- For authors with multiple posts, use this format instead of separate entries:

Links:

• {Title 1} — {YYYY-MM-DD}

{Summary of post 1}

• {Title 2} — {YYYY-MM-DD}

{Summary of post 2}

For cautionary tales, add ⚠️ after the author name in the heading:

3. Austin Starks (NexusTrade) ⚠️ cautionary tale

-->