linkedin-studio/scripts/trends

linkedin-trends-store

Persistent trend store — the foundation layer of the research engine (retning §5). A topic-tagged, provenance-bearing inventory of trend signals captured over time, so the engine accumulates history instead of starting amnesiac each session.

Twin of scripts/specifics-bank: same deterministic store / dedup / query discipline, different dedupe key — a trend is identified by its normalized title+URL, not by free-text content.

Generic by architecture

Nothing niche-specific lives here. A TrendRecord carries free-form topics tags and a free-form source string; which topics matter and which sources to poll are decided upstream (config/profile + the capture agent), never hard-coded in this module. The same store serves any niche.

Data location

The store lives under the per-user data dir (M0 data-path convention), so trend history survives plugin upgrades/reinstalls:

${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/trends/trends.json

LINKEDIN_STUDIO_DATA overrides the root. No path is hard-coded in prose.

Record shape (minimal generic core)

interface TrendRecord {
  id: string;          // sha256(normalized title+url).slice(0,12) — also the dedupe key
  title: string;       // headline, verbatim
  url: string;         // source URL, verbatim
  source: string;      // "tavily" | "websearch" | "manual" | <mcp-name>
  capturedAt: string;  // ISO-8601 date — when WE captured it
  publishedAt?: string;// optional source publish date (ISO-8601); distinct from capturedAt, first-sight, never back-filled
  topics: string[];    // query tags; unioned across re-captures
  summary?: string;    // optional, verbatim
}

Fields (relevance score, first-mover timing, status) can be added in a later slice without breaking the shape.

CLI

# Capture freshly-polled trends — the NORMALIZING BATCH path (the research agent's path):
# raw items on stdin → validate+normalize each → dedupe on title+url → union topics on
# re-capture → persist the source's publishedAt. Content-invalid items are reported in the
# summary errors[], never fail the run; the summary is {added, duplicates, merged, errors}.
echo '[{"source":"tavily","title":"Agentic workflows hit production",
        "url":"https://example.com/agentic","topics":["agents","engineering"],
        "publishedAt":"2026-06-20","summary":"Teams ship multi-step agents past the demo stage."}]' \
  | node --import tsx src/cli.ts capture [--store <path>] [--json]

# Add a SINGLE trend MANUALLY — raw flags, no normalization, publish-date-free:
node --import tsx src/cli.ts add \
  --title "Agentic workflows hit production" \
  --url "https://example.com/agentic" \
  --topics "agents,engineering" --source tavily \
  --summary "Teams ship multi-step agents past the demo stage."

# Topic-scoped history — trends matching these topics, ranked by overlap then recency
node --import tsx src/cli.ts query --topics "agents,engineering" [--json]

# Time-scoped history — newest first, optionally windowed/capped
node --import tsx src/cli.ts list [--since 2026-06-01] [--limit 10] [--json]

# Dated morning brief — rank the store by pillar-overlap then recency, write a dated
# Markdown file the SessionStart hook surfaces. Pillars come from the caller (user config).
node --import tsx src/cli.ts brief --pillars "agents,engineering" \
  [--fresh-days 7] [--out <dir>] [--store <path>] [--json]

Both capture and add dedupe on normalized title+url — re-capturing the same trend never appends a duplicate, it only unions any new topics in.

Morning brief (RE-R2b)

brief is the dated, surfaced read over the store (distinct from query/list, which are interactive dumps). It ranks the store against the user's pillars — overlap desc, then publishedAt ?? capturedAt recency — buckets into top (2+ pillars), single (1 pillar), and older (matched but outside the freshness window, default 7 days), and writes:

${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/trends/morning-brief/YYYY-MM-DD.md

The file's YAML frontmatter carries a single-line summary the SessionStart hook surfaces verbatim (zero-tsx — it reads the Markdown, never the TS CLI). Ranking uses only persisted fields; a persisted relevance score, an autonomous nightly trigger, and a seen-log freshness model are later slices.

Tests

cd scripts/trends
npm install
npm test     # deterministic store: normalize/id, load/save, dedup+union, query, history
npm run build