The Overnight Competitor Brief: The Watchlist, The Prompt, And The Setup That Actually Survives

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.