agentleFS
samsational-codesamsational-code/business-skills/watchlist-news-alert/SKILL.md

watchlist-news-alert

Skill0 starsChanged 2 months agoMITView on GitHub

Monitor a watchlist of companies, competitors, partners, vendors, customers, prospects, or people for recent, decision-relevant public news and produce an email-ready weekly alert. Acts as a lightweight news-alert substitute for account managers, competitive-intelligence and strategy teams, procurement and vendor-risk owners, BD and partnerships leads, recruiters, PR teams, and investors overseeing a list of names. Use whenever the user wants to check for news on watched entities, run a weekly scan, or asks "any news on my watchlist?", "did anything happen with [company]?", "run the alerts," "weekly competitor monitoring," "check my watchlist," "anything I should know about our vendors this week," or maintains a watchlist file and wants recent risk, financial, personnel, product, or relationship news surfaced. Trigger even when the user just says "run the alerts" or names a company and asks what's new, and especially for recurring weekly digests. The default lens is risk-first, not general news aggregation. Do NOT use for a full profile of one company — use the company-first-pass skill. Do NOT use to turn links the user already has into a recap — use the weekly-recap-writer skill.

The file

Show its rules and text

We split this skill into the rules it gives an agent

21 rules. About 0 are common, 21 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈21

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read the name and any context note.

    line 37
  2. Distinctive:

    Search the public web for news from the last 7 days only.

    line 40
  3. Distinctive:

    Keep only items relevant to the reader's decisions.

    line 41
  4. Distinctive:

    If an article is newly published but merely re-reports old news, either exclude it or label it clearly as recycled/background and assign …

    line 70
  5. Distinctive:

    If the publication date is unclear or unverifiable, assign lower confidence — or exclude it if you can't reasonably place it inside the …

    line 71
  6. Distinctive:

    Search across these alert categories.

    line 75
  7. Distinctive:

    Do not show these queries in the output.

    line 98
  8. Distinctive:

    Default output is an email-ready summary.

    line 132
  9. Distinctive:

    If there are only a few alerts, drop the section headers and keep it to a short executive summary plus the handful of items.

    line 187
  10. Distinctive:

    Write like an analyst briefing a colleague: concise, risk-first, sober, factual, scannable.

    line 191
  11. Distinctive:

    Don't confuse similarly named organizations, products, or people.

    line 195
  12. Distinctive:

    Don't include stale news outside the 7-day window, or treat old events as new.

    line 196
  13. Distinctive:

    Don't infer a relationship, contract, or ownership position unless the source supports it.

    line 197
  14. Distinctive:

    Don't overstate blogs, rumors, or chatter, or present speculation as fact.

    line 198
  15. Distinctive:

    Don't use recommendation language.

    line 199
  16. Distinctive:

    Don't say "no news found." If an entity is quiet, simply omit it.

    line 200
  17. Distinctive:

    Don't produce an exhaustive web dump — curate.

    line 201
  18. Distinctive:

    Don't show the search queries by default.

    line 202
  19. Distinctive:

    Ambiguous name: add disambiguating terms to searches and lower confidence on anything you can't cleanly attribute.

    line 208
  20. Distinctive:

    Watched person rather than organization: search the person's name with their current organization and title.

    line 209
  21. Distinctive:

    When an alert warrants a deeper look, run company-first-pass on the entity, or counterparty-diligence if it is a vendor, partner, or …

    line 218

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Watchlist News Alert

A lightweight, risk-first news monitor for anyone who oversees a list of outside entities — a sales team's key accounts, a strategy team's competitors, a procurement team's critical vendors, a partnerships lead's counterparties, a recruiter's target employers, a communications team's peer set, or an investor's holdings. It reads a simple watchlist of names, searches the public web for the last 7 days of decision-relevant news on each, and returns an email-ready alert summary.

Think of it as a news-alert substitute tuned for monitoring: the goal is not to aggregate everything written about an entity, but to surface what the reader would actually care about — risk events, financial moves, personnel changes, product and strategy shifts, and credible chatter — and to make it easy to tell the credible from the noise.

Core job

For each entry in the watchlist:

  1. Read the name and any context note.
  2. Infer likely aliases and key people automatically.
  3. Generate explicit web search queries internally.
  4. Search the public web for news from the last 7 days only.
  5. Keep only items relevant to the reader's decisions.
  6. Produce an email-ready summary, organized by relevance then source quality.

The two primary use cases are (a) telling the reader if anything bad or potentially decision-relevant happened with the watched entities, and (b) producing a weekly digest of public news on them.

The watchlist

The skill monitors watchlist.md, a simple bulleted list of names that the user can edit freely. Each entry may carry an optional note after a dash saying why it is watched ("— key account," "— primary competitor," "— sole-source supplier," "— acquisition target"). Read it first. If the file is missing or empty, ask the user which names to monitor (or to populate the file) rather than guessing.

The user may add or remove entries at any time, so always re-read the file at the start of each run. Don't assume the list is the same as last time. Use the context note, when present, to sharpen relevance: a pricing change matters differently for a competitor than for a vendor.

Aliases and key people

Names in the wild are inconsistent — a single organization shows up under several legal and colloquial names, and a lot of the most important news is attached to a founder, CEO, or senior leader rather than the organization itself. Before searching, infer the obvious aliases and key people so you don't miss coverage that uses a different label.

Infer:

  • Aliases — common short forms, legal-entity variants, former names, and spacing/punctuation variants. (Alphabet → also Google, Alphabet Inc.; Salesforce → Salesforce, Inc., salesforce.com; Toyota → Toyota Motor Corporation, Toyota Motor Corp.)
  • Founders / key people — where obvious and useful. (Salesforce → Marc Benioff; Nvidia → Jensen Huang; plus senior leadership where relevant.) For a watched person, infer their current organization and title.

Only surface inferred aliases or people in the output when it actually helps the reader — for example when ambiguity could affect confidence, or when a key alert came in under a founder's name rather than the organization's. Don't clutter a clean summary with disambiguation the reader doesn't need.

If a name is genuinely ambiguous (a name shared with an unrelated company, person, product, or place), add disambiguating terms to the searches — the industry, the headquarters city, a product name, the founder's name, or a known alias — and lower confidence on anything you can't cleanly tie to the right entity. Never confuse similarly named organizations or people; a wrong-entity alert is worse than a missed one.

Search window — be strict

The default window is the last 7 days from today's date. (Check today's date if unsure.) Be disciplined about this — the whole value of the digest is that the reader can trust everything in it is recent.

  • Exclude articles, posts, filings, summaries, or recycled stories published outside the 7-day window.
  • If an article is newly published but merely re-reports old news, either exclude it or label it clearly as recycled/background and assign low relevance.
  • If the publication date is unclear or unverifiable, assign lower confidence — or exclude it if you can't reasonably place it inside the window.

What to look for

Search across these alert categories. The first one is the priority — this is a risk-first tool.

  1. Negative / risk news — lawsuits, investigations, regulatory actions, fines, fraud allegations, sanctions, data breaches, outages, product recalls, safety incidents, layoffs, financial distress, bankruptcy, plant or office closures, reputational issues.
  2. Financial / performance news — earnings and guidance, funding rounds, revenue milestones, major contract wins or losses, pricing changes, credit or rating changes, unusual stock moves where public.
  3. Personnel news — executive departures and hires, founder succession, board changes, team lift-outs, internal disputes, union activity, notable departures in the function the reader cares about.
  4. Product / strategy news — launches, discontinuations, pricing or packaging changes, acquisitions and divestitures, partnerships, market entries and exits, capacity expansions, major roadmap announcements.
  5. Relationship news — only when the article names both the watched entity and a party the reader cares about (the reader's own organization, a shared customer, a competitor, a supplier). Do not infer a relationship, contract, or ownership stake unless the source says so or the watchlist note explicitly states it. Include major news about a connected organization only when the watched entity is directly mentioned.
  6. Chatter — lower-level public commentary from blogs, newsletters, podcasts, forums, review sites, employer-review sites, and social media. Include it, but make it visually easy to dismiss, never overstate it, and keep its confidence low unless it's independently corroborated.

Search queries (internal)

Generate explicit searches per entry. Cover, at minimum:

  • name + news
  • each alias + news
  • name + lawsuit / investigation / regulator / fine / breach / recall
  • name + earnings / revenue / funding / guidance / layoffs
  • name + contract / customer / pricing
  • name + CEO / executive / departure / hire / leadership
  • name + acquisition / partnership / launch / product
  • key person's name + organization name
  • name + blog / newsletter / forum / review

Do not show these queries in the output. They are working scaffolding. Only reveal the queries if the user explicitly asks to see them.

Source quality tiers

Tag every item with a tier. Used together with relevance to order the output and to calibrate confidence.

Tier 1 — Mainstream / official. Major wire services, national and international newspapers and broadcasters, the entity's own press releases and regulatory filings, court records, regulator and government announcements.

Tier 2 — Specialist / industry. Trade publications for the relevant industry, analyst and research-firm notes, industry newsletters with editorial standards, reputable databases and company-information services, regional business press.

Tier 3 — Chatter / blogs. Independent blogs, lightly sourced newsletters, podcasts, forums, review and employer-review sites, social-media-derived commentary. De-emphasize these visually and keep them easy to skip.

Relevance ranking

Organize output by relevance first, then by source quality within each relevance bucket.

  • High — directly names a watched entity and relates to risk, financial condition, personnel, product or strategy, regulatory or legal matters, reputation, or a relationship where the entity is explicitly mentioned. Likely to change what the reader does next.
  • Medium — mentions the entity, a key person, a business line, or a connected organization, but the decision implication is moderate or indirect.
  • Low — weakly connected items, chatter, recycled news, low-quality sources, or general market or sector commentary. Should be fast to scan and dismiss.

Confidence

Rate each alert:

  • High — direct mention of the watched entity, Tier 1 source, recent date confirmed, clear relevance.
  • Medium — credible source but somewhat indirect, or relevant but not fully specific.
  • Low — chatter, blog, weak source, unclear implication, or you only saw a limited snippet.

Paywalled sources

Include paywalled items when the headline and snippet are enough to convey relevance. Mark them Paywalled / snippet only and don't imply you read the full article when you only saw a snippet.

Output format

Default output is an email-ready summary. Length should scale with the number of meaningful alerts — keep it short when there's little to report, expand when there's a lot.

Use this structure:

Subject: Weekly Watchlist News Alerts — [Date]

Hi [Name],

Here are the notable public news alerts from the last 7 days for the watchlist.

## Executive Summary

- [1–3 bullets on the most important developments.]
- [Call out if the week was mostly quiet except for low-level chatter.]
- [Call out anything that may warrant follow-up.]

## High Relevance

### [Entity Name] — [Short Alert Headline]

**Why it matters:** [One or two sentences on relevance to the reader, using the watchlist note where present.]

**Source:** [Publication], [date]
**Source quality:** Tier [1/2/3]
**Confidence:** [High/Medium/Low]
**Link:** [URL]
**Note:** [Optional — paywalled, snippet-only, or ambiguity.]

## Medium Relevance

### [Entity Name] — [Short Alert Headline]

**Why it matters:** [One or two sentences.]

**Source:** [Publication], [date]
**Source quality:** Tier [1/2/3]
**Confidence:** [High/Medium/Low]
**Link:** [URL]

## Low Relevance / Chatter

- **[Entity Name]** — [Short item].
  Source: [Publication/blog], [date]. Confidence: Low.
  Why it is low relevance: [brief reason].

## Suggested Follow-Ups

- [Optional follow-up for an account review, vendor check-in, leadership meeting, or competitive response.]
- [Optional reminder to verify a paywalled or snippet-only source.]

Best,
[Sender]

If there are only a few alerts, drop the section headers and keep it to a short executive summary plus the handful of items. Use the full structure only when volume justifies it.

Style

Write like an analyst briefing a colleague: concise, risk-first, sober, factual, scannable. Be clear about uncertainty. Avoid hype, sensationalism, generic news-summary filler, and overly legalistic phrasing. Never use recommendation language ("switch vendors," "buy," "avoid," "drop the account") — this is monitoring, not advice.

What not to do

  • Don't confuse similarly named organizations, products, or people.
  • Don't include stale news outside the 7-day window, or treat old events as new.
  • Don't infer a relationship, contract, or ownership position unless the source supports it.
  • Don't overstate blogs, rumors, or chatter, or present speculation as fact.
  • Don't use recommendation language.
  • Don't say "no news found." If an entity is quiet, simply omit it.
  • Don't produce an exhaustive web dump — curate.
  • Don't show the search queries by default.

Edge cases

  • Quiet entity: omit it entirely rather than writing a "no news" line.
  • Everything low relevance: say in the executive summary that the week appears quiet based on the public sources reviewed, with only low-level chatter found.
  • Ambiguous name: add disambiguating terms to searches and lower confidence on anything you can't cleanly attribute.
  • Watched person rather than organization: search the person's name with their current organization and title; report role changes, public statements, and appointments; do not compile personal information beyond their professional public footprint.
  • User wants more depth: provide an appendix listing every included alert with a one-line rationale for its relevance rating.

Success criteria

A good run lets a user paste in a short list of names, run it once a week, and quickly answer: Did anything risky or decision-relevant happen? What deserves follow-up? What's credible versus chatter? Is everything actually within the window? What can be ignored?

Works well with

When an alert warrants a deeper look, run company-first-pass on the entity, or counterparty-diligence if it is a vendor, partner, or customer the organization depends on.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.