A decision-ready competitor digest gives every change an implication, an unknown and an owner

Start from changes you have already verified

The input is a list of changes you have opened and dated: a pricing page that changed, a feature in a competitor's release notes, a new integration, a job post that signals a direction. Each item carries the URL you looked at and the date you looked. If you are still working from a raw alert feed, the alert-triage lesson filters it down to the changes worth a human's attention, and the page-change lesson captures each one as a dated before-and-after. Neither is required. A hand-kept list with one link and one date per line is enough.

Keep that list in the Claude Project you use for competitor work, so company context and approved messaging are already there when Claude drafts. For this digest, require Claude to use only the verified notes and label every implication as inference. Delete any new fact that is not in the source list.

Write one line per change: the fact, then the implication

Each line has two sentences with a visible seam between them. The first states what the source shows. The second states what that plausibly means for your product, phrased as an inference, so a reader can see where the source stops and your reading starts.

The lines below are invented practice material, with placeholder competitors, to show the two sentence types side by side.

Claude is useful for the second sentence after the first is settled. One short prompt constrains the draft to the verified notes.

Prompt: one implication sentence per verified change

Below is a list of competitor changes I have verified myself. Each has a
source and a date. For each change, write one sentence stating what it
plausibly implies for [our product] in [market], beginning with "Likely"
or "Possibly". Do not restate the fact, do not add any fact that is not in
the list, and do not state the implication as certain. If a change has no
clear implication for us, write "No clear implication".

Read each implication against its fact. If it introduces a price, a date, a customer or a capability that is not in your list, delete it. Treat every implication as inference, and verify each source before it enters the digest.

Flag what you have not confirmed

An unknown is anything the implication depends on that you did not see in a source. Write it as its own clause after the implication: "Unknown: whether the new tier is sold in Japan." Do not fold it into the implication sentence, where a hedge reads as a fact once the digest is forwarded.

Keep last week's unknowns visible until someone resolves them. An unknown that quietly disappears is read as answered.

Name one owner and one action, or write "no action"

Give each digest line an owner and a next action so the intended follow-up is explicit: "Owner: [sales lead], update the integrations row on the Emca battlecard by Friday." "No action this week" is a valid entry. It records the decision for the next review.

Arcade's competitive analysis template makes the same case from the monitoring side: each competitor has a named owner, and an alert should trigger a specific action. The digest is where that action gets written down.

Claude may suggest an owner from the team context you provide, but a person must confirm the assignment.

Cut the rest to a footer

Anything with no implication and no action moves to an "Also seen" line at the bottom: the fact and its link, nothing else. The body then holds only lines with a stated next action, which keeps the digest compact.

If the footer repeatedly outgrows the body, treat that as a signal to tighten the upstream triage. This is an editorial check, not a measured threshold.

Check it before you send

• Every fact line links to a source you opened, with the date you opened it.
• Every implication begins with "Likely" or "Possibly" and adds no fact that is not in the list.
• Every unknown is a separate clause, not a hedge inside the implication.
• Every line names one owner and one action, or says "No action this week".
• The footer holds only facts and links.

Send it where the readers already are, usually a sales channel in Slack or a short email. Save the sent digest in the Project so next week has the exact dated record. Chat search or memory may retrieve prior context when enabled, but availability and scope vary, and neither replaces the saved digest. Anthropic's Project guide explains how Project knowledge is shared across chats in that Project.

Running it on a schedule, and what that still leaves with you

Opening Claude by hand every week is the weak point of this method. Claude Cowork's scheduled tasks, checked September 16, 2026, can run hourly, daily, weekly, on weekdays or on demand, with the same connected tools, skills and plugins as an ordinary Cowork task. They are available on paid plans (Pro, Max, Team and Enterprise). Cloud tasks can run while the computer is off when they use cloud-accessible sources; tasks that need local files or apps run locally. Require a source for every verified change. Claude may suggest an owner from supplied team context, but a person must confirm the assignment before the digest is sent.

When a weekly manual pass stops being enough

If you can keep the source list current and complete the rechecks consistently, the DIY method remains workable; the build-versus-buy guide compares the ongoing work. If collection and distribution repeatedly fall behind, Steve's competitive-intelligence product is an option to evaluate.