Competitor Monitoring

Competitor Monitoring

You watch competitors for a salesperson. They read the result in an app, not in the chat — the Sales Companion iOS app parses a fenced watch block from your daily memory note. Your job is not to write a nice report but to detect reliably what changed since the last run, and to leave out everything else.

Keep the tone factual. No "exciting", no "interestingly". A salesperson reads this in twenty seconds in the morning. Write names, titles and details in the user's language.

The four stores

watch/targets.json is the watchlist. Scheduled runs cannot call cron at all — the tool is blocked there — so they can only know the full list from this file. Change it in the same step as the cron task, every time:

{"targets": [
  {"id": "<target-id>", "name": "<display name>", "kind": "company",
   "focus": "<what to watch>", "schedule": "<e.g. täglich 07:30>",
   "url": "<website>", "task_id": <number from cron add>}
]}

This and every other <…> shape in this file is a template: fill in real values from the user's request, watch/targets.json or this run. Never write a template, or an example company name from this file, into any file.

task_id is the number cron add reports ("Scheduled … task #42 …"); pass it as taskId to update and remove.

Why these stores: the memory tool may only write today's daily note, and only memory files are synced to the platform, where the app reads them. A workspace file never reaches the app, so it holds your own state.

A. Set up a watch

This happens in a chat with the user, where cron is available.

1. Clarify who and what to look for. If the focus is missing, ask exactly once ("What should I watch at Allianz — prices, products, people?"). If the website is missing, look it up yourself; do not ask.

2. Derive a stable id from the name: lowercase ASCII, hyphens, no umlauts — allianz-de, barmenia, jane-doe. If watch/targets.json already has it, update that watch instead of adding a second one.

3. Create the cron task:

   cron action=add
     cron="<minute> <hour> * * *"
     tz="<user's IANA time zone>"
     channel="<the user's email address>"
     prompt="Competitor monitoring: use the competitor-monitoring skill,
             read its SKILL.md and follow it. Target: <target-id>
             (<display name>, <website>), kind=<company|person>,
             focus: <what to watch>."

   • Pass tz with the user's IANA time zone so the run keeps its local time across daylight-saving changes. If you do not know it, ask; for a German-speaking user, Europe/Berlin is the usual answer.
   • channel is required when the request comes from a web chat session: the tool refuses to schedule there, because the output of a task created without a delivery channel would be discarded. Use the user's email address or another configured messaging target. If none is known, say so plainly instead of trying without one.

4. Add the target with its task_id to watch/targets.json (create the file if it is missing).

5. Do not create watch/<id>.json. The first scheduled run records the baseline; a file created now would only be empty.

6. Write the result block right away (section C) with the updated list and "findings": []. Otherwise the new target only appears in the app after the first scheduled run.

7. Confirm in one sentence: "I'm watching Allianz from tomorrow morning, focus pet insurance."

Changing a watch (time, focus): cron action=update taskId=<task_id> from watch/targets.json, then update the entry there. Never add a second task for the same target.

Removing a watch: cron action=remove taskId=<task_id>, remove the entry from watch/targets.json, delete watch/<id>.json, write the block again.

B. A scheduled run

You receive the task's prompt. cron is not available here; do not try it. Work strictly in this order:

1. Read the watchlist and the previous state. read watch/targets.json and read watch/<id>.json. If the state file is missing or its snapshots are empty, this is a baseline run: fetch the sources, save them as the state (step 6) and report nothing as a finding — there is nothing to compare against yet. Still write the block with "findings": [].

2. Fetch the current state. Use several sources, not just one:

   • web_search with freshness: "week" on company name plus focus
   • web_fetch on the pages that belong to the focus (pricing, product, press pages) — they are listed in the state under snapshots
   • for kind=person, also search name plus role. Social activity is only partly visible with the available tools, so rely on interviews, talks, press releases and job changes.

3. Compare. For each source: did the substance change? Ignore counters, dates, cookie banners, ordering and rewording that does not change meaning.

4. Judge. A finding only counts if it falls into one of these categories. Use the category names as given; the app shows them as labels.

   category	Example
   Preis (price)	plan more expensive, new discount, tiers changed
   Produkt (product)	new product, benefit dropped, terms changed
   Partnerschaft (partnership)	cooperation, reseller, integration
   Finanzierung (funding)	funding round, acquisition, sale
   Personal (people)	change in management or sales leadership
   Stellen (hiring)	notable job ads that reveal a direction

   Everything else — guide articles, blog posts, social chatter, redesigns, anniversaries — is severity: "minor" or does not belong in the block at all. severity: "significant" is only for what the salesperson must know today because it changes a conversation; only significant triggers a notification on their phone. When in doubt, minor: a phone that buzzes too often gets muted.

5. Deduplicate. Give every finding a fingerprint: category, source URL and the new value in a few words — Preis|https://allianz.de/preise|Premium 27,90 €. If the state's reported map already has that fingerprint, the change was reported before: drop it from this run. Otherwise assign a new id (see section C).

6. Write the result block first (section C). Only if the memory append succeeded, go on to step 7. If it fails — for example because today's note is full — stop and leave the state untouched, so the next run finds the same changes again instead of losing them. Reply with the failure line (step 8).

7. Then update the state. write watch/<id>.json:

   {"target": "<target-id>",
    "snapshots": {
      "<source url>": {"fetched_at": "<ISO time>", "summary": "<short>",
                       "key_facts": {"<fact>": "<value>"}}},
    "reported": {
      "<fingerprint>": {"id": "<finding id>", "first_seen": "<YYYY-MM-DD>"}}}

   Keep summary short — this file is your memory, not an archive. Drop reported entries older than 30 days; the app only sees about two weeks of notes anyway.

8. Reply with a short digest. Your final reply is delivered to the task's channel — usually the user's inbox — after every run, so it must be readable at a glance. Plain text in the user's language, no preamble, no JSON, no tables, no sign-off. Exactly one of these shapes:

   • significant findings, one line each, at most five: <Name>: <finding title> — <source url>
   • only minor findings: <Name>: <n> kleinere Änderungen, Details in der App.
   • nothing new: <Name>: nichts Neues.
   • baseline run: <Name>: Beobachtung läuft, Ausgangsstand gespeichert.
   • the block could not be written: <Name>: Lauf fehlgeschlagen — <reason in a few words>.

If you find nothing, write the block anyway, with "findings": []. The app tells "nothing happened" apart from "the run did not take place".