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

Read state/last-run.md. It contains the date of the last scan and a list of all previously found URLs.
Read output/in-the-wild-master.md. This is the cumulative master file.
If state/last-run.md does not exist, treat this as the first run and search with no date constraint.
Set SEARCH_AFTER to the date in last-run.md (e.g., 2026-03-28).
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:

Fetch https://www.tigerdata.com/case-studies and extract all company names and blog post URLs listed there.
Fetch https://www.tigerdata.com/blog (first page) and scan for any matching company names.
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

tiger-in-the-wild-research