Competitor Watch

Competitor watch

Competitive and market intelligence built from what actually crossed your screen, fused with external monitoring.

The thing this does that nothing else does. Every competitive intelligence product in the category monitors a supplied list of names and URLs, and two of them literally bill per competitor tracked. That model cannot surface a name nobody typed in, and it cannot tell you what your market is talking about this week. This skill reads your own field of view. A competitor that turns up three times in one week across a client call, a community thread, and a friend's screenshot is a signal no URL monitor produces. That is the spine of the skill, and the sightings log, the velocity ranking, and the new-entrant detection all exist to serve it.

It is not another news digest. If the external half is all that runs, say so and say why.

Purpose

Keep a named set of competitors and market shifts under observation on a weekly beat, built first from what actually crossed the user's screen and only then from external monitoring, so the output is what moved in this user's market rather than what a press release said.

Three failures it exists to prevent:

1. The list nobody can leave. URL monitors only see names somebody already typed in. A competitor entering the field of view for the first time is invisible to them, so new-entrant detection is a first-class output here rather than a feature.
2. Volume mistaken for velocity. Ten steady mentions is not news. Zero to four is. Ranking by raw count produces a digest that reports the same three incumbents forever.
3. The manufactured week. A recurring digest that invents analysis to fill a quiet period earns its way into the ignored pile. A quiet week gets one line.

Capability gate

List the tools available in this session and use the real tool names. Do not assume the names in this file are spelled the way your session spells them, and do not assume a tool exists because it is named here.

• Required: the Littlebird MCP, on a Power or Pro plan. If search_user_context is not available, the MCP is not connected. Stop and tell the user. There is no degraded mode worth shipping: without the internal half this is a web search with extra ceremony, and the user deserves to be told that rather than handed one.
• Expected: whatever web search and fetch tools the session carries. Sessions differ. List them and use the real names. If none are present, produce the internal half in full, mark the external and reconciliation sections as unrun with the reason, and say plainly that reconciliation is the section that needed both halves.
• Plan check: LB_INTERNAL_GET_SUBSCRIPTION_STATUS when you need to explain a routine limit or a capability gate to the user.

Littlebird MCP calls used

Every search_user_context call carries date_range: week by week for the digest, month by month for a backfill. At most 7 queries per call, split across parallel calls rather than widened into one.

External monitoring runs on whatever web search and fetch tools the session actually carries. There is no Littlebird web search tool. List the session's tools and use their real names.

Trigger

• "competitive intelligence", "what are our competitors doing", "competitor tracking"
• "weekly competitive digest", "what moved in the market this week"
• "deep dive on COMPETITOR", "who else are we up against", "new entrant"
• "add this to the watchlist", "update the watchlist"
• The weekly routine fires and the user comes to collect

Two modes:

Routine cadence

Weekly, Monday 07:30 local, so the week's competitive picture lands before the week's calls. Confirm the day and time with the user. The research archive supports a weekly beat but not a specific weekday.

Routines can be created from an interactive session. Offer to create this one, show the user the exact prompt text and schedule from Routine wiring below, get approval with AskUserQuestion, then call LB_INTERNAL_CREATE_ROUTINE. Do not tell the user to go set it up by hand. Check LB_INTERNAL_GET_SUBSCRIPTION_STATUS first, because routine count is plan-limited. Creation is blocked only from inside a running routine, which is why the routine itself never does this.

Read before running

Process

1. Establish or confirm the watchlist. Before any retrieval.

Read references/watchlist-setup.md and run the setup interview with AskUserQuestion: market frame, Tier 1 competitors, Tier 2 adjacent names, aliases and product names and domains and founder names, tracked topics and shifts, and ambiguity traps.

If a watchlist already exists at competitor-watch/watchlist.md, read it, show the user the current list with its last-confirmed date, and ask what changed. Confirm quarterly at minimum.

Retrieval without a watchlist degrades into an unbounded sweep, which overflows the result limit and returns noise. Do not skip this step.

2. Run the internal passes.

Read references/sighting-extraction.md. Five narrow parallel passes, all windowed:

At most 7 queries per call. Separate parallel calls rather than one wide call. Sweep week by week for the digest, month by month for a backfill.

For any meeting hit, read the structured summary from LB_INTERNAL_GET_MEETING before the transcript. Take attribution from the Decisions and Action Items blocks, never from raw transcript chunks tagged [Others].

A competitor named by a client or prospect on a call is the highest-value sighting this skill produces. Surface those first.

3. Deduplicate, then build the sightings log.

Collapse consecutive captures of the same page, list and detail views of the same thread, a notification and the item it points to, and the same article in two tabs. Undeduplicated counting manufactures velocity that does not exist.

Record date, entity, source app, context type, whose screen it was, a one-line summary, a receipt, and a confidence rating. Sort chronologically. Retrieval returns relevance order, not time order.

4. Count frequency, compute velocity.

Rank by velocity against the trailing baseline, not by raw volume. Zero to four is a bigger event than ten to eleven, and the digest says so. Where no prior periods exist, report raw counts and say the baseline is unavailable.

Apply the counting convention in references/sighting-extraction.md, and state in the output that it is a working convention rather than a researched constant. The weak-signals literature is explicit that no practical formula separates signal from noise, so a skill that presents a threshold as settled science is lying.

5. Detect new entrants.

Read references/new-entrant-detection.md. Extract candidate names from the category passes and the meeting pass, then diff three ways: against the watchlist including aliases, against the Declined list, and against prior periods. Report first appearances and recurring-but-untracked separately. One bounded external check per candidate that cleared the threshold.

Propose. Never add. Candidates go into Proposed, awaiting confirmation with their evidence and a promote, decline, or defer decision from the user.

6. Run the external half.

Read references/external-monitoring.md. Per Tier 1 entity: pricing, positioning, product and launches, funding, personnel, public claims. Tier 2 gets funding, launch, and positioning only unless it produced internal sightings this period.

Every external claim carries a URL and a date, and a vendor claim is reported as a claim. On the first run most of this is baseline rather than change, and the digest says so.

7. Reconcile.

What they say about themselves against what your market is saying about them. Agreement, divergence, and the possible readings of each divergence marked as inference. Conflicts stay conflicts. Do not resolve a disagreement by picking the more interesting reading.

8. Write the so-what, fenced off.

Three points maximum, explicitly marked as inference, each naming the observations it rests on and what would make it wrong. A quiet period gets one line. Manufacturing analysis to fill the section is how a recurring digest earns its way into the ignored pile.

9. Write the artifact.

Per references/digest-template.md.

Output

Confirm the base directory with the user on first run. All three files are internal working documents.

Evidence standards

Apply references/evidence-standards.md in full. The rules that bite hardest here:

• Receipts on every internal claim, URLs on every external claim. A claim with neither is an inference and gets labeled as one.
• Observed, inferred, external, unknown, and the kind is visible to the reader. The so-what section is entirely inference and is fenced accordingly.
• Screen capture shows what the user was viewing, not what they wrote. A sighting proves something was on screen. It does not prove the user endorsed it, shared it, or wrote it.
• Partial rosters reported as partial. Collapsed UI lists produce incomplete sets by construction.
• Absence is absence. "No sightings of X in this window" is supportable. "X went quiet" is not.

Empty retrieval

If the passes return nothing for the window: report the gap and stop. Name the window, the passes run, and the entities searched. "No sightings of any tracked entity between DATE and DATE across snapshots, messages, and meetings" is a correct and useful output.

Do not pad from training data, do not substitute plausible examples, and do not convert silence into a claim that the market was quiet. If the external half also returns nothing, say the period produced no evidence in either direction and offer to widen the window.

Guardrail

The risk this skill carries is the line between competitive awareness and taking something you were not entitled to have, and the skill sits close enough to that line to need it stated in the body rather than filed in a guide.

Read references/ethics-and-boundaries.md before the first run. The line: intelligence from what you legitimately saw in the ordinary course of business is normal competitive awareness, and every enforcement case in the research archive involves somebody taking, accessing, or buying material they were not entitled to have, never somebody drawing a conclusion from something they saw. Deliberately mining a partner's or client's screen share for their confidential data is the other thing, and this skill refuses it. Material under NDA or shared in confidence stays out entirely. Third-party content is theirs, not yours: screen capture of another person's post, dashboard, or screen share is competitive input, the intelligence derived from it stays internal, and nothing captured from another person's screen gets republished, quoted publicly, or shared outward.

Routine wiring

The weekly digest runs as a Littlebird routine. Offer to create it, show the user the exact schedule and prompt text below, get approval with AskUserQuestion, then call LB_INTERNAL_CREATE_ROUTINE. Creating it generates a first report immediately, then it runs on schedule. Do not tell the user to go set it up by hand. A routine cannot create or rewrite routines, so this step never happens from inside a running routine.

Schedule: {"frequency": "weekly", "time": "07:30", "week_days": ["MO"]}. Monday morning, so the week's competitive picture lands before the week's calls. Confirm the day and time with the user; the archive supports a weekly beat but not a specific weekday.

Title: Competitor watch weekly

Prompt text, pass verbatim:

Weekly competitive intelligence sweep for the last 7 days.

FIRST, BEFORE ANY SEARCHING: read your own previous reports with
LB_INTERNAL_GET_ROUTINE_REPORTS, limit 8. Build a list of every entity, new-entrant
candidate, and external change you have already reported, with the date you first
reported each one. You are reporting what is NEW and what is ACCELERATING this week.
You are not restating the standing competitive landscape. Anything you already
reported and that has not moved does not get repeated.

Then read the watchlist at competitor-watch/watchlist.md if it is available to you. If it
is not, use the tracked entity names carried in your previous reports and say in the
report that you worked from report history rather than the current watchlist.

Then run these searches, all bounded to the last 7 days:

1. search_user_context with filters data_source snapshots, one query per tracked
   entity using its name plus its strongest alias. Maximum 7 queries per call, split
   across calls if needed.
2. search_user_context with filters data_source snapshots, category-shaped queries
   that do not name any entity: alternative to, pricing page, we switched to, launch
   announcement, raised funding, has anyone tried, our stack.
3. search_user_context with filters data_source messages, same entity names, using
   search_queries_messages.
4. LB_INTERNAL_SEARCH_MEETINGS with each tracked entity name as the query, plus
   shortlist language: also looking at, who else are you talking to, currently using.
   A competitor named by a client or prospect on a call is the most important sighting
   you can find. Report those first.

Deduplicate before counting anything. Consecutive captures of the same page, a list
view and a detail view of one thread, a notification and the item it points to, and
the same article in two tabs are ONE sighting. Undeduplicated counting invents trends.

Then write the report in this order:

WHAT MOVED. Maximum three items, ranked by change against the prior weeks in your
report history, not by raw count. Something going from zero mentions to four is a
bigger finding than something steady at ten. One line each, with a receipt.

NEW IN YOUR FIELD OF VIEW. Names appearing for the first time across all your prior
reports, separated from names that appeared before but were never added to the
watchlist. Each with its first sighting, source app, context, and receipt. Propose
them for the watchlist. Do NOT treat them as tracked. Do not re-propose a name the
user already declined.

SIGHTINGS LOG. Chronological. Date, entity, source app, context type, one-line
summary, receipt.

STILL RUNNING. One line per item you have now reported in three or more consecutive
weeks with no change. Name it, give the week count, and say the standing read has not
moved. Do not re-explain it. If any such item has now appeared for four or more
consecutive weeks, escalate it: state plainly that it has been open for that long, that
weekly observation is not resolving it, and name the specific decision or deep dive the
user should run in Cowork with the competitor-watch skill.

QUIET WEEK RULE. If nothing is new and nothing accelerated, write exactly one line
saying so, plus the sightings log if there were any sightings at all, and stop. Do not
manufacture analysis. Do not restate the landscape. A one-line report is the correct
output for a quiet week.

EVIDENCE RULES. Every internal claim carries a receipt in the form
[Day, Month DD, YYYY HH:MM TZ | app]. Screen capture shows what was VIEWED, not what
the user wrote or endorsed. Collapsed UI lists ("and 4 others") make any roster partial,
so report the named set and the size of the unnamed gap. If the searches return nothing,
say so and stop. Never fabricate to fill a section.

BOUNDARIES. Content that was on the user's screen because another person put it there
is competitive input and the intelligence stays internal. Never quote or reproduce
another party's confidential material, screen share contents, dashboards, or anything
shared under NDA. Report the market fact, not the other party's private data.

Close with one line naming what the user should open in Cowork if anything here needs
work: the competitor-watch skill, for a deep dive on a named entity or to update the
watchlist.

Notifications: enable push. Email is the user's call.

Handoff to Cowork. The routine observes and reports; it does not write files, run external research, or ask for approvals. When the routine surfaces a new-entrant candidate, an escalated repeat item, or a divergence worth chasing, the user opens Cowork and runs this skill on demand. The on-demand run reads the routine's own past reports via LB_INTERNAL_GET_ROUTINE_REPORTS before doing anything else, so the deep dive starts from what the routine already established rather than from scratch.

Updating the routine. LB_INTERNAL_UPDATE_ROUTINE replaces the whole prompt and the whole schedule. Always read LB_INTERNAL_GET_ROUTINE_CONFIG first and edit from the current text.

Ship Gate

Ship Gate removed, research-only skill, produces no committable code.

Related skills