The Overnight Competitor Brief

Why does competitor monitoring always quietly get dropped?

Because it is a task with no deadline. Nothing breaks the week you skip it, so it gets skipped, and then you find out about the pricing change from a customer who is already asking for a discount.

The tools built for this have their own problem. They compare yesterday's version of a page against today's and flag anything that is not identical, so a competitor swapping a photo gets the same alert as a competitor halving their price. Within a fortnight you stop opening the emails.

What changed is that Claude Code Routines shipped in April 2026, and they run on Anthropic's cloud rather than your machine. That distinction is the whole thing. The check happens at six in the morning whether your laptop is open, closed, off, or in a bag at an airport.

So the job becomes possible to automate properly, and the remaining work is deciding what actually deserves your attention. That is what the watchlist and the prompt below are for.

1. The three ways to schedule Claude, and why only one works here

This trips people up constantly, so it is worth thirty seconds.

/loop repeats a task inside your current session. It dies when the session dies. Useful while you are sitting there working, useless overnight.

Desktop scheduled tasks run on your own machine. They need the computer awake and the app open. If your laptop sleeps through the scheduled time, you get one catch-up run when it wakes, covering only the most recent missed fire, not all of them.

Cloud Routines run on Anthropic's infrastructure. Your machine can be off entirely and the run still happens.

For a morning brief, only the third one does the job. If you set this up as a desktop task, it will work perfectly during testing and then silently stop the first weekend you close the lid.

One limit to plan around. The minimum interval for a routine is one hour. That is far more frequent than this workflow needs, so it is not a constraint here, but it rules out anything closer to real time.

2. Before you start

A paid Claude plan. Routines are available on Pro, Max, Team and Enterprise. There is no free tier.

Claude Code. Either the desktop app or the command line.

A folder for this work, connected to GitHub. This matters more than it sounds, and section six explains why. A cloud routine clones a repository to run, so the repository is the only thing that persists between runs.

Twenty minutes. Fifteen to build the watchlist properly, five for the setup.

3. The watchlist

Create a file called watchlist.md in your folder. This is the artifact the whole workflow runs on, and its quality decides whether the brief is useful or noise.

markdown

# Competitor Watchlist

## My business
[Two or three sentences. What you sell, who buys it, and what you
compete on. Claude needs this to judge whether a change matters to
you specifically rather than being generically interesting.]

## Tier 1: check daily
[The sources where a change would make you act the same week.]

- Industry news: [SEARCH TERMS, e.g. "invoicing software funding"]
- [COMPETITOR] pricing: [URL]- [COMPETITOR] pricing: [URL]## Tier 2: check every three days
[Where change is slower but still meaningful.]

- [COMPETITOR] changelog or release notes: [URL]- [COMPETITOR] blog: [URL]- [COMPETITOR] reviews on [G2 / Capterra / Trustpilot]: [URL]## Tier 3: check weekly
[Slow signals that reveal direction rather than events.]

- [COMPETITOR] careers page: [URL]- [COMPETITOR] LinkedIn headcount: [URL]## What counts as a change worth reporting

Report:
- Any pricing change, including a plan being added, removed or renamed
- A new feature that overlaps what I sell
- Three or more roles opening in one function
- The same complaint appearing in reviews more than twice
- Funding, acquisition, leadership change
- A competitor entering [YOUR SEGMENT]

Ignore:
- Design and copy changes with no substantive difference
- Blog posts that are not announcements
- Single reviews, positive or negative
- Job posts for roles they always have open
- Anything already reported in the last 14 days unless it has moved

## Context that changes the ranking
- Our price is [X]. Anything undercutting it materially is urgent.
- We are weakest on [FEATURE]. A competitor shipping it matters more
  than usual.
- We are strongest on [FEATURE]. Someone copying it is worth knowing.
- [COMPETITOR] is the one we lose deals to most often. Weight them
  heavier than the rest.

The two sections that decide everything. The ignore list is what stops the daily brief becoming another feed you stop opening. And the context section is what lets Claude rank rather than just list, because "our price is X" is what turns a competitor's new tier from a fact into an urgent one.

Start with three competitors, not ten. You can add more once you know the brief is worth reading.

4. The reporting prompt

Save this as brief-prompt.md in the same folder.

markdown

Read watchlist.md before doing anything else.

Check every Tier 1 source. Check Tier 2 sources if they have not been
checked in three days, and Tier 3 if not checked in seven. The state
file tells you when each was last checked.

Compare what you find against baseline.md. Report only genuine
changes, judged by the rules in the watchlist.

For each change, give me exactly four things:

1. WHAT CHANGED
   One sentence, factual, no interpretation.

2. WHY IT MATTERS TO US
   Two sentences maximum, tied to something specific in my business
   context. If it does not affect us, say so plainly rather than
   inventing a reason it might.

3. WHAT I WOULD DO
   One concrete action, or "nothing this week" if that is the honest
   answer. Never suggest something vague like "monitor the situation".

4. SOURCE
   The direct link, and the date the change appeared if you can
   establish it.

Rank by urgency, not by category. Put anything needing a decision
this week at the top.

If nothing meaningful changed, say "No material changes" and stop.
Do not pad the brief to make it feel worth reading.

Write the finished brief to briefs/YYYY-MM-DD.md using today's date,
so it is sitting in the repository waiting for me.

Then update baseline.md with the current state of every source you
checked, and update state.md with today's date against each source.

Commit all three files.

Do not contact anyone, post anything, or take any action outside this
repository, unless I have set up a delivery channel and told you to
use it.

Why the four fields. Most monitoring output stops at what changed, which leaves you doing the actual work. The second and third fields are the ones that turn information into a decision, and the fourth is what lets you check it rather than trusting it.

The "no material changes" instruction is not optional. Without it you get a brief every morning regardless, padded with trivia, and you stop reading it inside a fortnight. A monitoring system that is allowed to say nothing happened is one you keep trusting.

5. Setup, step by step

Step one. Create a folder, put watchlist.md and brief-prompt.md in it, and connect it to a GitHub repository. Claude Code can do this for you if you ask it to.

Step two. Create two empty files in the same folder, baseline.md and state.md, plus an empty folder called briefs. Section six explains what the first two are for, and the third is where each morning's brief lands.

Step three. Run it manually once, before scheduling anything:

Read brief-prompt.md and run today's competitor brief.

Read the output properly. This first run establishes your baseline and shows you whether the watchlist is producing signal or noise. Expect to edit the ignore list after seeing it.

Step four. Run it manually a second time the next day. The first run has nothing to compare against, so the second run is the first honest test of whether change detection works.

Step five. Create the routine. Either at claude.ai/code/routines in the browser, or with /schedule in the command line, which sets it up conversationally.

Point it at your repository, use the prompt from step three, and set it to run early enough that the brief is waiting when you start work.

Step six. Check it fired the next morning. Then leave it alone for a week before changing anything, because a week of output tells you more about the watchlist than any amount of tuning on day one.

Where the brief actually goes

Worth being explicit about, because the run happens on a machine you never see.

The default is the repository. The prompt writes each brief to briefs/ with the date as its filename and commits it. So the brief is waiting in the repo when you open it, and you get a dated archive of every brief you have ever received, which becomes genuinely useful around month three when you want to know when a competitor first moved on something.

If you want it to arrive instead of waiting. A routine is a prompt, one or more repositories, and a set of connectors. Connect a messaging or email connector and add one line to the prompt telling it to send the finished brief there. That is an external action, so gate it: give the routine that one connector and nothing else, and keep the prohibition on everything beyond it.

What to avoid. Do not give an unattended overnight routine broad write access to your tools so it can be helpful in ways you did not specify. One narrow delivery channel is the entire external permission this workflow needs.

6. The part most coverage skips: every run starts from nothing

This is the section that decides whether your workflow survives past its second day.

A cloud routine clones your repository into a fresh environment, runs, and then destroys that environment. Every run is stateless. Nothing carries over.

For most scheduled work that is fine. For change detection it is fatal, because detecting a change requires knowing what things looked like before. A stateless run has no idea what the pricing page said yesterday, so it either reports everything as new or reports nothing at all.

The fix is that the repository persists even though the environment does not. So the memory has to live in files that get committed.

baseline.md holds the current state of every source. What each pricing page says, the latest changelog entry, the current open roles. The routine compares against this, then rewrites it.

state.md holds when each source was last checked, which is what makes the tiered cadence work at all.

The final instruction in the reporting prompt commits both. Without that commit, the run happens, the brief arrives, and the environment is destroyed along with everything it learned. Next morning it starts from nothing again.

The second trap in the same area. If your routine needs an API key, it goes in the Cloud Environment settings panel as an environment variable, and you have to tell Claude in the prompt to read it from the environment rather than from a file. By default it may look for a local file first and fail silently. Silently is the problem word. You get a brief that looks fine and is missing a source.

7. The three artifacts you need

One, the watchlist. Section three. Everything downstream is capped by it.

Two, the baseline and state files. Section six. Two files, both committed, or none of this works twice.

Three, a written decision log, 200 to 400 words to start and growing weekly, and almost nobody has one. One file where you record what the brief flagged and what you actually did about it. Three lines a week. The reason this matters is that a monitoring system is only worth running if it changes decisions, and without a log you will have no idea whether it ever did. After two months it tells you plainly whether to keep the routine, and it also becomes the record of why you priced something the way you did, which is worth more than the brief itself.

8. If something goes wrong

9. Honest limits

It reads public pages, and not everything is public. Pricing shown only after a sales call, features behind a login, and anything in a private beta will not appear. This finds what a competitor publishes, which is most of what matters and not all of it.

Judgment about impact is genuinely hard. Claude can tell you a competitor added a plan at a lower price. Whether that threatens you depends on things it cannot see, like how your customers actually buy. Treat the second and third fields as a starting position rather than a conclusion.

Anything scheduled degrades quietly. A URL changes, a page moves behind a login, a competitor rebrands, and the brief keeps arriving looking normal with one source silently absent. Reread your watchlist once a month against reality.

Keep the permissions narrow. The prompt forbids acting outside the repository apart from one delivery channel you set up deliberately. That line should stay as written. A monitoring routine with broad write access is a different risk category, and an unattended overnight job has no business having it.

Routines are still labelled research preview. Behaviour and limits have moved since launch, so check the current documentation if something works differently to this.

10. What this changes

Competitor monitoring has always been a discipline problem rather than an information problem. The information was public. What nobody had was a reason to look at it on a Tuesday when nothing was on fire.

Moving it onto infrastructure that does not depend on you removes the discipline requirement entirely, and what you are left with is a smaller and better question. Not whether to check, but what you would actually want to be told. That question is worth the twenty minutes, and it is the only part of this that stays yours.