Automate a weekly competitor watch with a Claude Code skill and a routine

Checking a handful of competitor pricing pages every week is the kind of task everyone means to keep up with and nobody does past week three. It is rules-based, it is repetitive, and it does not need your judgment until something changes — which makes it a textbook candidate for the "hand to AI" bucket in the one-week automation audit. Spotting that a task belongs in that bucket is the easy part. Wiring it so it keeps running after you close your laptop is where most people stop.

Claude Code has two separate primitives for this, and combining them correctly is the part nobody explains: a skill defines what to do, a routine defines when to do it, and the fresh-clone-every-run model means git has to hold the memory between runs. Get any one of those three wrong and the automation either does not persist or silently does nothing.

Why /loop is the wrong tool here

The obvious first instinct is /loop, since it already runs a prompt on a schedule. It is the wrong primitive for this job for two reasons that matter for anything meant to run unattended: a /loop task is session-scoped, so it stops the moment you close that Claude Code session, and even a task you keep alive expires automatically seven days after creation. Fine for babysitting a deploy for an afternoon. Not fine for a check you want running in three months without you thinking about it.

The tool built for that is a routine — a saved prompt, repository, and connector set that runs on Anthropic-managed cloud infrastructure, independent of your machine being on. Routines are available on Pro, Max, Team, and Enterprise plans with Claude Code on the web enabled, created at claude.ai/code/routines or with /schedule from the CLI.

Step 1: write the skill

A skill is a markdown file with instructions Claude can invoke by name. Commit one to the repo the routine will clone:

---
name: competitor-watch
description: Fetch tracked competitor pages, diff against the last snapshot, report what changed.
---

1. Read `competitors/list.txt` — one URL per line.
2. Fetch each URL. Extract the pricing table and the "what's new" or
   changelog copy.
3. Compare the extracted content against `competitors/snapshot.json`
   from the previous run.
4. If nothing changed, say so in one line and stop. Do not write a diff
   for whitespace or layout noise — only content changes count.
5. If something changed, write a short summary (what changed, old value
   vs new value, per competitor) to `competitors/latest-diff.md`, update
   `competitors/snapshot.json` with the new content, and commit both.

Add competitors/list.txt with the URLs you want tracked and an initial competitors/snapshot.json (even an empty {} is fine — the first run just populates it).

Step 2: schedule the routine

From any Claude Code session, describe it in natural language:

/schedule weekly, Monday 8am: run the competitor-watch skill against
competitors/list.txt in this repo. If the skill produced a diff, open
a PR titled "Competitor watch: <date>" with the diff summary in the
description.

Claude walks through the same setup the web form collects — repository, environment, trigger — and saves it to your account. /schedule list shows everything scheduled, /schedule update edits one, /schedule run fires it immediately to test before you walk away. Weekly is one of the built-in presets; if you want a cadence the presets do not cover, /schedule update accepts a raw cron expression, with a one-hour floor on how often a routine can fire.

Two defaults are worth trusting rather than fighting. Routines can only push to claude/-prefixed branches unless you explicitly enable unrestricted pushes — which means the PR-on-change design above is not a workaround, it is the safer default: you get a diff to glance at instead of a bot silently editing files. And because each run clones the repository fresh with no persistent local disk, competitors/snapshot.json committed back to git is the routine's memory. There is nowhere else for state to live between Monday and Monday.

Step 3: fix the network access gotcha before you trust it

This is the part that will burn you silently. A routine's default cloud environment uses Trusted network access — enough to reach package registries, cloud provider APIs, and common dev domains, but arbitrary websites are blocked. A fetch to a competitor's pricing page returns a 403 with x-deny-reason: host_not_allowed, and the routine still finishes and shows a green run status, because a green status only means the session started and exited without an infrastructure error — not that your prompt succeeded.

Fix it before the first real run: open the routine, click the environment selector, open its settings, switch Network access to Custom, and add the competitor domains you listed in competitors/list.txt (or choose Full for unrestricted access if the domain list will keep changing). Then open the transcript of at least the first run, not just the status dot, and confirm it fetched the pages rather than quietly hitting a wall every Monday for a month.

Step 4: optional — push it to Slack instead of a PR

If a PR is too easy to ignore, add a Slack connector under the routine's Connectors tab (connect it once at claude.ai/customize/connectors first) and change the skill's last step to post the summary to a channel instead of only committing it. Connector traffic is routed through Anthropic's servers, so it works without adding Slack's domain to your allowed-domains list — only the direct page fetches need that.

The pattern generalizes

Once this shape is working — a skill that knows the one job, a routine that knows the cadence, git holding the state between runs — it is not specific to competitor pages. The same three pieces cover watching a GitHub repo for new releases, scanning a job board for a role opening, or triaging yesterday's support tickets into themes before your Monday standup. The audit that found the competitor check in the first place will surface the next candidate too — the wiring is now a template, not a one-off project.