Method
Scheduled Routines
The three recurring runs that drive this repo, with their exact configuration. Kept in version control so they can be recreated, audited, or edited without reconstructing them from memory.
Each Routine spawns a fresh session with no memory of previous runs. The prompts below are therefore standalone. They point at RUNBOOK.md, which is the real operating procedure.
Where these live
claude.ai/code/routines → New routine.
Note: /schedule in the is not available from inside a Claude Code on the web session. That surface is told to use the web UI instead. It does work from a local terminal.
The estate copy runs the same prompts through tools/ai_read_cron.py, scheduled by ops/the-ai-read.cron installed as /etc/cron.d/the-ai-read. The wrapper verifies the expected issue after each slot and escalates through Galley if the slot produces nothing. Keep the prompts below authoritative for both claude.ai and estate-side runs.
Common settings
| Field | Value |
|---|---|
| Repository | builtwithclaude4313/the-ai-read (site: theairead.com) |
| Environment | Needs network access to arbitrary news domains: see below |
| Connectors | None. Runs write to the repo and nowhere else. A routine can use every tool of every connector left on, without prompting, so leave none on |
| Trigger | Schedule |
Schedule times
Times are entered in your local timezone and converted automatically, so there is no UTC math to do and DST is handled for you: the run stays at the same wall clock time year-round.
Naming. The AI Read then an em dash then the type, so the four sort together in the routines list and the type is what your eye lands on:
| Routine name | Schedule | Preset available? |
|---|---|---|
| The AI Read — Daily Brief (AM) | 6:00 AM daily | Yes: Daily |
| The AI Read — Daily Brief (PM) | 2:00 PM daily | Yes: Daily |
| The AI Read — Weekly Issue | 9:00 AM Sunday | Yes: Weekly |
| The AI Read — Monthly Wrap | 8:00 AM on the 1st | No: see below |
The PM brief needs enough distance from the morning that something has happened, and enough of the US session behind it to be worth reading. Early afternoon does both. Sunday runs all three: the weekly is a retrospective, the briefs are the news, and the weekly reads the week's dailies as its input. Give the AM brief time to commit before the weekly starts, which is why the weekly sits at 9:00 AM rather than 7:00.
Runs may start a few minutes late by design (stagger). The offset is consistent per routine.
Monthly has no preset. Two options:
- Create it with any preset, then run
/schedule updatefrom a local terminal and set cron0 8 1 * *. (Cron there is the one place UTC/DST matters, verify the next run time it reports.) - Don't schedule it. Open the routine on the 1st and click Run now. It fires once a month, costs the most, and is the one run worth launching deliberately.
Option 2 is the recommended default until the cadence has proven itself.
Network access, the setting most likely to break a run
The Default environment uses Trusted network access, which only permits an of package registries and common development domains. The daily brief fetches arbitrary news sites, and those requests would fail with 403 host_not_allowed.
Before the first run, open the routine's environment and set Network access to Full, or to Custom with the news domains you expect plus the default list. If the first daily brief comes back thin or reports fetch failures, this is why.
1. The AI Read — Daily Brief (AM)
Cron: 0 13 * * *
Produce today's MORNING DAILY BRIEF for The AI Read, and feed the three
libraries. There is a second, lighter brief in the afternoon; this is the full
one and it owns the libraries.
Repository: builtwithclaude4313/the-ai-read (work on main). Site: https://theairead.com
1. Read docs/RUNBOOK.md and follow it. It is authoritative; this prompt is a
pointer. Where they disagree, the runbook wins. Sections: §0 Preflight,
§1 Daily brief, §3b The three libraries, §4 Ledger, §5 Commit.
Read docs/METHODOLOGY.md, docs/VOICE.md and docs/PERSONAS.md before writing.
2. Establish today's real date with `TZ=America/Los_Angeles date +%F`. That is
the publication's day. Never assume it from training, and never use UTC: a run
after 5pm Pacific is already tomorrow in UTC and would misfile the edition.
3. Write the brief per §1. File it at reports/daily/YYYY-MM-DD-am.md and open
it with "# Morning Brief, August 12th 2026". Front matter sets the byline by
weekday.
A BRIEF IS A RANKED LIST OF NEWS STORIES. No ## The Lead, no ## The
Signal: those were section names invented to hold stories. TWENTY
STORIES MINIMUM, most important first, each one an H2 headline with its
body under it. Take thirty on a heavy day. The site numbers them and
builds the contents rail from the headings, so never number by hand.
Under the H1, a standfirst that is a HOOK, NOT A SUMMARY: three or four
short sentences, around forty words, one per story and only the biggest
ones. Say what happened and stop. No analysis, no what-it-means, no
closing line naming the pattern of the day: that is what the stories are
for, and a reader handed the whole day up here has no reason to read the
day. Then the stories. Then ## Editorial, ## Prediction Watch and
## Sources, in that order.
A STORY NEVER NAMES THE EDITION IT IS IN. Not "this brief", not "this
morning's brief". Every story is republished on AI News under a date with
no edition around it, so a story that cites its own brief is pointing at
something the reader cannot see. Say "this morning", "yesterday".
A STORY IS THE NEWS, NOT AN ACCOUNT OF OUR COVERAGE OF IT. It opens on
what happened, never on what we said before. A story MAY point at an open
call, which is what the auto-link is for; it may NOT do the accounting.
"That resolves Prediction 2026-08-12-T1 correct" belongs in Prediction
Watch. dedupe.py fails the run on either fault.
`**Update.**` IS FOR A STORY THAT GENUINELY DEVELOPS ONE ALREADY
PUBLISHED, and the site renders it as a chip above the headline rather
than as words in the sentence. Do not put it on straight news.
PREDICTION WATCH IS WRITTEN FOR SOMEBODY WHO HAS NEVER READ THE LEDGER.
One bolded label from the closed set (More likely now / Less likely now
/ No change / Supporting evidence / New call / Settled: we were right /
Settled: we were wrong), then the claim in PLAIN WORDS from the
prediction's own title, then what today did to it, then "Settles August
6th 2027". Never open with a raw id, never say "moved toward". Reference
it as "(Prediction F4)" so the whole phrase links and the reader can see
where it goes; use the full id "(Prediction 2026-08-11-F1)" when a
suffix names more than one call, which the build will tell you.
End with what did not happen.
The China / open-weights beat is named explicitly in your run reply
every time, even to say nothing happened.
4. THE BRIEF IS ONE OUTPUT. THE THREE LIBRARIES ARE THREE MORE. The run is not
finished until all three are fed, and they are NOT sections of the brief.
Feed them whether or not anything about them made today's news.
- data/watch.jsonl 2-4 podcasts/videos -> Media
- data/tools.jsonl 4-6 entries -> Technology
- data/ventures.jsonl 2-4 entries -> Startups & IPOs
TOOLS: two reasons to list something and a day needs both. `reason` says
which: "new" = you would not have found this (the repo, the MCP server, the
CLI, the weekend project); "consequential" = you have to act on this (a price,
a license, a capability that unblocks a use). An entry is often both, so file
it under the stronger one. Look at GitHub trending, Hugging Face, the MCP
registries, Show HN, Product Hunt, and the release notes of tools already
tracked, as well as the big launches.
REQUIRED SPREAD, every day: at least three of the four `scale` values, always
including something small (project or tool) AND something at platform scale,
across at least three categories, AND both `reason` values. Following the news
alone produces ten models from four companies, all consequential and none of
them findable anywhere else; that is the failure this exists to stop.
VENTURES: not just IPOs, and NOT a link to a batch directory. Go through MORE
THAN ONE accelerator: Y Combinator's current and previous batch, then
Techstars, Entrepreneur First, South Park Commons, AI House, Neo, Antler,
a16z Speedrun. Open the company pages.
HOW TO PICK, in priority order: (1) could this have been built two years ago?
If yes it is a company, not a signal. (2) Do the founders know something
non-obvious, as opposed to having a strong resume? (3) Can you state the
strongest case against? If not you are writing a directory entry; put the
objection in the note. (4) Never pick on traction, which selects for whoever
ran the best launch. Two companies doing the same thing do not both get
spotlighted in one week.
The IPO half is NOT a selection problem: the pipeline is small enough to
enumerate, so log all of it. `rumored` requires a named outlet citing its
sourcing; a well-followed post is not a rumor of record.
REQUIRED, every day: at least TWO named company spotlights. A spotlight is a
`company` record with `batch` set, and it needs `founders` (names and where
they came from), `deal` (the terms: YC's standard is $500K, as $125K
post-money for 7% plus $375K uncapped MFN), `site` (the company's OWN
website, taken from the profile page's link-out, never guessed),
`accelerator` (from the vocabulary in tools/catalog.py), and a note over 180
chars that says why the company is worth watching. `url` stays the profile
page. The two spotlights must come from TWO DIFFERENT accelerators. Never
invent a founder, a domain or a term; if the page does not say it, leave it
out.
`status` separates rumored / filed / priced / listed / cohort / raised and
must never blur them.
Targets, not quotas, EXCEPT the two REQUIRED lines above, which are floors.
A thin day beats padding elsewhere. If a library gets nothing, say which and
why in your reply rather than letting the gap pass silently.
5. Also update, where the day touches them:
- data/timeline.jsonl: events that will still matter in six months. `tags` is
a LIST, most events carry two. Name the entities.
- data/predictions.jsonl: new or resolved calls. Every call needs title, why,
plain and criterion. §4 explains each.
- data/entities.json: any company or person referenced and not already there.
- data/glossary.json: any jargon, acronym or term of art you used that an
average reader would not know. If you had to look it up
to write the sentence, define it, and then go back and
apply that test harder, because your sense of what is
obvious is not the reader's. AISI, multimodal, Hugging
Face and agentic all went undefined for a week.
One or two sentences, under 260 chars, plus a link, and
the definition gets voice-checked like any other prose.
§3c has the schema. You never mark terms by hand; the
build marks the first use on every page automatically,
capped at three per paragraph.
6. Before pushing, run all of these and fix anything they report:
python3 tools/predictions.py check && python3 tools/predictions.py render
python3 tools/watch.py && python3 tools/timeline.py && python3 tools/catalog.py
python3 tools/catalog.py brief # today's spread and spotlights
python3 tools/glossary.py && python3 tools/dedupe.py
python3 tools/fonts.py check && python3 tools/voice.py && python3 tools/build_site.py
Then commit and push per §5.
7. Reply with the headline, what went into each of the three libraries, a link to
the commit, and anything flagged uncertain, unverified or contested.
docs/VOICE.md is the voice standard and tools/voice.py enforces the mechanical
half. No em dashes. No manufactured candor ("to be honest", "it's worth noting").
No AI register (delve, tapestry, testament to, moreover, showcase, underscore).
No empty intensifier standing where a number belongs. US spelling and US date
order: behavior, center, organization, and "August 10th 2026", never
"10 August 2026". A direct quotation keeps its source's spelling. Every sentence states a
sourced fact, makes a claim someone could argue with, or connects the two. The
checker cannot tell whether a sentence says anything, so read it back and cut
the ones a reader could not disagree with.
Every item links to its source. Write the tier marker with the URL on it:
[A](https://primary-source)[B](https://outlet) at the very END of the item, one
set per item, never per sentence. [A] is the announcement or filing itself, [B]
the best write-up, and a bare [C] still needs a URL. Tier markers that are part
of a legend rather than a citation stay unlinked. The ## Sources list stays
complete on top of that.
STANDING RULES. Never fabricate a URL: an unconfirmed link is marked unconfirmed
and the site renders it as a search. Never average contested figures; show the
disagreement and pick the best-sourced value. Tier every number [A]/[B]/[C]/[?].
Dated issues are immutable, corrections append, style-only fixes are allowed
where meaning is unchanged. Do not publish the same story or recommend the same
episode twice; update the existing record instead. Personas change the argument,
never the facts.1b. The AI Read — Daily Brief (PM)
Cron: 0 21 * * *
Produce today's AFTERNOON DAILY BRIEF for The AI Read. It catches up on what
broke since this morning. It is lighter than the AM brief by design.
Repository: builtwithclaude4313/the-ai-read (work on main). Site: https://theairead.com
1. Read docs/RUNBOOK.md §1 and follow it. It is authoritative; this prompt is a
pointer. Also read docs/VOICE.md before writing.
2. Establish today's real date with `TZ=America/Los_Angeles date +%F`. That is
the publication's day. Never assume it from training, and never use UTC: a run
after 5pm Pacific is already tomorrow in UTC and would misfile the edition.
3. READ THIS MORNING'S BRIEF FIRST: reports/daily/YYYY-MM-DD-am.md. You cannot
write the afternoon brief without knowing what the morning one said.
4. Write it to reports/daily/YYYY-MM-DD-pm.md, opening with
"# Afternoon Brief, August 12th 2026". Budget ~20-30 searches.
Front matter carries THE SAME byline as this morning; it is one person's day.
Same shape as the morning: a ranked list of H2 headlines with bodies, most
important first. Aim for twenty. Take fewer without apology if the afternoon
did not produce twenty. ## Sources last. NO Editorial (the day's argument was
made this morning). NO Prediction Watch either, unless a call actually
settled this afternoon: see 5.
5. THE ONE THING THIS BRIEF CANNOT FAIL AT IS BEING NEW. A reader who comes
back at three in the afternoon and finds the morning's stories restated
stops coming back at three in the afternoon.
A story from the AM brief may reappear ONLY if it genuinely moved, and the
item must lead with **Update.** and say what changed:
- **Update.** A second independent check landed this afternoon and
closes the verification question, confirming X at Y. [A](url)
THE MARKER IS A LABEL, NOT AN OPENING. The site lifts it out of the
sentence and renders it as a chip above the headline, so what follows it
is the first thing a reader reads. Use it only when the item genuinely
develops something already published.
A STORY IS THE NEWS, NOT AN ACCOUNT OF OUR COVERAGE OF IT. Never open with
what we said before. Not "this morning we flagged tonight's prints", not
"yesterday we called this the stress test, here is what it showed". The
reader does not know what we said and is not asking. Open on what
happened. dedupe.py FAILS the run on a story that opens on us.
A STORY NEVER NAMES THE EDITION IT IS IN, and the afternoon is where that
goes wrong, because it is always referring back. Not "this morning's
brief", not "tomorrow's PM brief". Every story is republished on AI News
under a date with no edition around it. Say "this morning", "yesterday",
"tomorrow afternoon". The standfirst is exempt; the feed drops it.
NO PREDICTION WATCH unless a call actually settled this afternoon, in
which case run one with that single entry. Never settle a call inside a
news story: "that resolves Prediction 2026-08-12-T1 correct" is
bookkeeping, and dedupe.py fails on it.
An update is not a recap. If you cannot name what changed, cut the item.
`python3 tools/dedupe.py` compares every item against the last two days of
briefs and FAILS the run on an unmarked repeat. Run it before you push.
6. FIVE STORIES ON A QUIET AFTERNOON IS AN HONEST ANSWER. Padding is the
failure, brevity is not. Never invent a story to reach a number, and never
pad an item with restatement to make it look longer.
7. The AM run owns the three libraries and has already fed them. Add to
data/tools.jsonl, data/ventures.jsonl, data/watch.jsonl, data/timeline.jsonl,
data/glossary.json only if this afternoon actually turned something up.
Any jargon you used that a reader would not know still goes in the glossary.
8. Before pushing, run all of these and fix anything they report:
python3 tools/predictions.py check && python3 tools/watch.py
python3 tools/timeline.py && python3 tools/catalog.py
python3 tools/glossary.py && python3 tools/dedupe.py
python3 tools/fonts.py check && python3 tools/voice.py && python3 tools/build_site.py
Then commit and push per §5.
9. Reply with the item count, what was genuinely new against what was an
update, a link to the commit, and anything unverified or contested.
Same voice standard as the morning brief. No em dashes. No manufactured candor.
No AI register. No closing epigram: if deleting the clause after the comma loses
no information, it was decoration. US spelling and US date order, "August 10th
2026". Every item carries its own source link, written [A](url)[B](url) at the
END of the item. Never fabricate a URL. Tier every number [A]/[B]/[C]/[?].2. The AI Read — Weekly Issue
Cron: 0 16 * * 0
Produce this week's FULL ISSUE for The AI Read: the main event.
Repository: builtwithclaude4313/the-ai-read (work on main). Site: https://theairead.com
1. Read docs/RUNBOOK.md and follow it. It is authoritative; this prompt is a
pointer. Sections: §0 Preflight, §2 Weekly issue, §3b The three libraries,
§4 Ledger, §5 Commit. Read docs/METHODOLOGY.md, docs/VOICE.md and
docs/PERSONAS.md before writing.
2. Establish today's real date with `TZ=America/Los_Angeles date +%F`. That is
the publication's day. Never assume it from training, and never use UTC: a run
after 5pm Pacific is already tomorrow in UTC and would misfile the edition.
3. Read the week's seven daily briefs BEFORE searching, including this
morning's, which the AM routine committed a few hours ago. This is synthesis, not
concatenation: say what the week MEANT, which is not visible from any single
day. Then write the issue per §2. Every section ships. Byline is ISO week
number mod 3.
4. DATING. The file is named for the Sunday it ships and the site renders that as
the week it covers, "Week of 10-16 August 2026". Do NOT put a date in the H1.
The kicker carries it and a headline repeating it will disagree eventually.
A weekly may also be a multi-part issue directory, reports/weekly/YYYY-MM-DD/
with a README carrying the coverage window. Vol. 1 is one. Use the single file
unless the week genuinely needs the parts.
5. Log new predictions. A weekly with no new falsifiable calls has failed at its
main job. Each needs title (one line, under 78 chars, no hedge clauses), why
(the reasoning, written for a reader), plain (what counts, in plain English)
and criterion (the machine-checkable version). Resolve anything that came due:
edit in place, never delete, never soften a call after the fact.
6. Feed the three libraries with what the week turned up (§3b). The dailies do
the bulk; the weekly adds what only became visible with seven days of context,
and is the right moment to notice that three entries are really one story.
Also update data/timeline.jsonl, data/threads.md and data/entities.json.
7. Before pushing, run all of these and fix anything they report:
python3 tools/predictions.py check && python3 tools/predictions.py render
python3 tools/watch.py && python3 tools/timeline.py && python3 tools/catalog.py
python3 tools/catalog.py brief # today's spread and spotlights
python3 tools/glossary.py && python3 tools/dedupe.py
python3 tools/fonts.py check && python3 tools/voice.py && python3 tools/build_site.py
Then commit and push per §5.
8. Reply with the headline, the new calls you logged, what went into the
libraries, a link to the commit, and anything still contested.
docs/VOICE.md is the voice standard and tools/voice.py enforces the mechanical
half. No em dashes. No manufactured candor ("to be honest", "it's worth noting").
No AI register (delve, tapestry, testament to, moreover, showcase, underscore).
No empty intensifier standing where a number belongs. US spelling and US date
order: behavior, center, organization, and "August 10th 2026", never
"10 August 2026". A direct quotation keeps its source's spelling. Every sentence states a
sourced fact, makes a claim someone could argue with, or connects the two. The
checker cannot tell whether a sentence says anything, so read it back and cut
the ones a reader could not disagree with.
Every item links to its source. Write the tier marker with the URL on it:
[A](https://primary-source)[B](https://outlet) at the very END of the item, one
set per item, never per sentence. [A] is the announcement or filing itself, [B]
the best write-up, and a bare [C] still needs a URL. Tier markers that are part
of a legend rather than a citation stay unlinked. The ## Sources list stays
complete on top of that.
STANDING RULES. Never fabricate a URL: an unconfirmed link is marked unconfirmed
and the site renders it as a search. Never average contested figures; show the
disagreement and pick the best-sourced value. Tier every number [A]/[B]/[C]/[?].
Dated issues are immutable, corrections append, style-only fixes are allowed
where meaning is unchanged. Do not publish the same story or recommend the same
episode twice; update the existing record instead. Personas change the argument,
never the facts.3. The AI Read — Monthly Wrap
Cron: 0 15 1 * *
Produce this month's WRAP for The AI Read: light, the weeklies did the work.
Repository: builtwithclaude4313/the-ai-read (work on main). Site: https://theairead.com
1. Read docs/RUNBOOK.md and follow it. It is authoritative; this prompt is a
pointer. Sections: §0 Preflight, §3 Monthly wrap, §3b The three libraries,
§4 Ledger, §5 Commit. Read docs/METHODOLOGY.md, docs/VOICE.md and
docs/PERSONAS.md before writing.
2. Establish today's real date with `TZ=America/Los_Angeles date +%F`. That is
the publication's day. Never assume it from training, and never use UTC: a run
after 5pm Pacific is already tomorrow in UTC and would misfile the edition.
3. Scaffold with `python3 tools/new_issue.py monthly YYYY-MM`, then write the wrap
per §3. This looks back across the month's weeklies, it is not fresh
reporting. Resist re-researching what is already written down.
4. DATING. The issue README carries the coverage window and the site reads it to
label the issue: `**Coverage window:** 1 - 31 August 2026`. Eight days or less
renders as "Week of X", longer states its range. Component files carry NO date
in their H1s. Editorials lead with the article headline as the H1, not the
section name, and set their author in front matter.
5. Do the reckoning. This is the part that only happens here:
- Resolve every call whose date has passed. status -> correct / wrong /
partial / void, with a resolution_note naming the source that settled it.
Never delete a call. Never soften one after the fact. void is only for calls
made unresolvable by outside events, with the reason recorded.
- Run `python3 tools/predictions.py score` and publish the Brier score and the
calibration table.
- Write about the MISSES specifically. Reasoning error, bad model, bad data, or
right thesis and wrong clock? A wrap that reports the hits and glosses the
misses is worthless, and the archive is the product.
6. Prune the libraries (§3b). A month is the right interval to check whether
anything in tools.jsonl has been superseded, abandoned or shut down, and to
resolve what actually happened to each filing in ventures.jsonl. A directory
nobody prunes becomes a list of dead links. Update data/threads.md too: which
threads are dead, which have hardened into facts, which are still live.
7. Before pushing, run all of these and fix anything they report:
python3 tools/predictions.py check && python3 tools/predictions.py render
python3 tools/watch.py && python3 tools/timeline.py && python3 tools/catalog.py
python3 tools/catalog.py brief # today's spread and spotlights
python3 tools/glossary.py && python3 tools/dedupe.py
python3 tools/fonts.py check && python3 tools/voice.py && python3 tools/build_site.py
Then commit and push per §5.
8. Reply with the month's verdict, the score, what you got wrong and why, a link
to the commit, and anything still contested.
docs/VOICE.md is the voice standard and tools/voice.py enforces the mechanical
half. No em dashes. No manufactured candor ("to be honest", "it's worth noting").
No AI register (delve, tapestry, testament to, moreover, showcase, underscore).
No empty intensifier standing where a number belongs. US spelling and US date
order: behavior, center, organization, and "August 10th 2026", never
"10 August 2026". A direct quotation keeps its source's spelling. Every sentence states a
sourced fact, makes a claim someone could argue with, or connects the two. The
checker cannot tell whether a sentence says anything, so read it back and cut
the ones a reader could not disagree with.
Every item links to its source. Write the tier marker with the URL on it:
[A](https://primary-source)[B](https://outlet) at the very END of the item, one
set per item, never per sentence. [A] is the announcement or filing itself, [B]
the best write-up, and a bare [C] still needs a URL. Tier markers that are part
of a legend rather than a citation stay unlinked. The ## Sources list stays
complete on top of that.
STANDING RULES. Never fabricate a URL: an unconfirmed link is marked unconfirmed
and the site renders it as a search. Never average contested figures; show the
disagreement and pick the best-sourced value. Tier every number [A]/[B]/[C]/[?].
Dated issues are immutable, corrections append, style-only fixes are allowed
where meaning is unchanged. Do not publish the same story or recommend the same
episode twice; update the existing record instead. Personas change the argument,
never the facts.Managing them
From claude.ai/code/routines, click a routine to open its detail page:
- Run now: fire immediately without waiting for the schedule. Use this to smoke-test.
- Repeats toggle, pause without losing the configuration.
- Pencil icon: edit name, prompt, repositories, environment, connectors, triggers.
- Past runs: each run is a full session you can open and read.
A green run status does not mean the brief was good. It means the session started and exited without an infrastructure error. Blocked network requests and task-level failures show up inside the transcript, not in the status dot. Open the run and read it, at least for the first week.
What changed on August 13th 2026
Two prompts need editing: AM and PM. Weekly and Monthly are unchanged.
Most of the day's work was the site rather than the writing, and the site is generated, so a run picks it up without being told. Three things did reach the writing, and two of them contradict text sitting inside the stored prompts, which is why a pointer to the runbook was not enough this time.
| Change | Where it is enforced | Prompt edit |
|---|---|---|
| The standfirst is a hook, not a summary. Three or four short sentences, ~40 words, biggest stories only. It had grown to 110 words and told the whole day before the day started. | RUNBOOK.md §1, new_issue.py | AM: yes. The prompt still said "one paragraph written the way you would tell a friend", which is the instruction that produced the 110-word version. |
| A story never names the edition it is in. Every story is republished on AI News under a date with no edition around it, so "this brief" points at something the reader cannot see. | RUNBOOK.md §1 | PM: yes. Its **Update.** example said "the morning brief left open", teaching the pattern the rule forbids. The afternoon is where this goes wrong, because it is always referring back. |
Section renames: Tech & Tools → Technology, Watch & Listen → Media, IPOs & Incubators → Startups & IPOs. The weekly's ## Watch & Listen section is ## Media. | RUNBOOK.md §1, §3b, new_issue.py | AM: cosmetic. The library list names the section each file surfaces in. Nothing breaks if it is stale, since the data files did not move. |
Everything else from the day needs no instruction. The AI News feed, the story pill, the date rail, the per-date pages, the source labels, the menu names and the section subheaders are all generated from content that already exists in the form the runbook asks for.
What changed on August 12th 2026
Two briefs a day now. The morning brief is the full one and owns the three libraries; the afternoon brief catches up on what broke since, aiming for twenty stories too and taking fewer without apology. Paste the new PM prompt as a fourth routine and repaste the AM prompt, which changed. The reason is a reader habit: a site that never moves past breakfast teaches people to check once and forget it.
- Files are
YYYY-MM-DD-am.mdandYYYY-MM-DD-pm.md. The site reads the half and renders "August 12th 2026, PM", labels the home page "This afternoon", and sorts the afternoon brief above the morning one. python3 tools/dedupe.pyis in all four validator chains. A story may repeat within two days only as an item leading with**Update.**. Unmarked repeats fail the run.- Both halves carry the same byline. The afternoon piece is the same person's follow-up on their own day.
Two floors were added to the daily, because both libraries failed the same way on their first day and neither failure is visible from inside a run:
- Tools need a spread of sizes. Three of the four
scalevalues every day, always including something small and something at platform scale, across three categories. Following the news produces ten models from four companies. - Ventures need two named company spotlights. A
companyrecord withbatchset is a spotlight, and it requiresfounders,deal,siteand a real note. A link to a batch directory is a link to somebody else's list, not coverage. - A spotlight links to the company's own website.
siteis what the card title goes to;urlstays the accelerator profile, and both show as labeled rows on the card. - Two accelerators, minimum, every day.
acceleratoris a controlled vocabulary intools/catalog.py, and the brief check counts distinct ones. YC has the best directory, which is exactly why a section left alone becomes a YC newsletter. - How a spotlight gets picked is now written down (§3b): could it have been built two years ago, do the founders know something non-obvious, can you state the case against, and never pick on traction. The IPO half is not a selection problem at all: enumerate the pipeline, and
rumoredneeds a named outlet. - Tools carry a
reason,neworconsequential, and a day needs both. Novelty and consequence are each a good reason to list something; a day that is all of one is the failure. python3 tools/catalog.py briefchecks both against today's additions and says what is missing. It is in all three validator chains.
What changed on 11 August 2026
If you are pasting these for the first time since then, the prompts are not small edits on the old ones. They were rewritten. The substantive changes:
- The daily produces four things, not one. The brief, plus a contribution to each of Media, Technology and Startups & IPOs. The libraries are fed whether or not anything about them made the news.
- Media is no longer a brief section. Episodes go to the library.
- Every item carries its own source link, written as
[A](url)at the end of the item. The old convention put every URL in a Sources list at the foot of the page. - Two new libraries,
data/tools.jsonlanddata/ventures.jsonl, withtools/catalog.pyvalidating both. The check command changed. - No dates in component headlines. The site derives the period from the coverage window, and renders "Week of X" for anything eight days or shorter.
- Editorials lead with the article headline as the H1, with the section name in the kicker and the author in front matter.
- Media Watchlist and the slide decks are retired. Do not scaffold them.
Why these prompts carry no procedure
Structure, length, item counts, charts and search budget all live in docs/RUNBOOK.md, which is version-controlled and reviewable. The prompts point at it.
This matters because the prompts live in a web UI that nobody diffs. The first version of these routines duplicated the runbook's specifics, and within a day the two had drifted: the prompt still said "400-700 words, 10-15 searches" after the runbook had moved on. A pointer cannot go stale. Change the runbook, not these.
The one thing the prompts do spell out is which data files a run has to touch, and the validators to run before pushing. That is deliberate: a run that writes an episode as prose instead of into data/watch.jsonl produces something that looks right and quietly breaks the library, and no error appears anywhere. Naming the files is cheaper than letting a run discover the convention by not following it.
Changing a schedule
Edit the Routine and ops/the-ai-read.cron, not this file alone, then update the table above to match. The three drifting apart is how a run ends up firing at a time nobody expects.
If a run fails
Scheduled runs report back by email and push. Estate-side runs also escalate through Galley when the expected file is missing, a prerequisite is missing, the working tree is dirty, or the commit did not reach origin/main. The most likely causes, in order:
- CI staleness check: the run edited
data/predictions.jsonlwithout re-renderingPREDICTIONS.md. Fix:python3 tools/predictions.py renderand commit. - Ledger validation: a new prediction has a criterion too vague to check. The error names the id.
- Broken internal link: a report links to a file that doesn't exist.
All three fail loudly rather than silently publishing something wrong. That is the intent.