The morning report is already written

Write the recipe once. Read the report every weekday.

1. Write the report recipe. A project-kind recipe in Act mode: read what merged, what is ageing, what failed overnight, and say which of them needs a person. It reads the repository and leaves it unchanged.
2. Put the window in the prompt. Ask for everything since{{last_success_at}}. The runtime fills it at fire time.
3. Turn on the Slack notifier for the project. It is a built-in server that ships off; enabling it is what lets the run post its own report into a channel.
4. Give it a cron line. Five fields, host timezone, minute granularity, per project.
5. Read it with coffee. Every fire also lands in the host’s own record with a start, an end, an outcome, and a summary — so a report that did not arrive is still an answered question.

It fires on its own and keeps a record.

The report runs on the computer’s clock rather than anyone’s calendar. An automation is a project-scoped schedule for a literal command, a saved command button, or a recipe, in standard five-field cron at minute granularity and the host’s local timezone. The schedule belongs to the project on the computer, so no phone is involved and it fires with nobody attached.

Every fire records a durable start, end, outcome, summary, error, and a reference to whatever it produced — and the summary outlives the worktree, so a discarded run is still a readable record.Run now uses the same dispatcher for testing and leaves the next cron time where it was.

What goes on the line is a prompt your team writes, not a report we shipped, so it covers what you actually want to know. Teams tend to start here:

• What merged yesterday, in plain language
• What needs a human
• Overnight failures
• New crash groups matched to code
• Flaky-test movement

It says “since last time” and means it.

The prompt knows when the recipe last succeeded, so the report states the window it actually covers instead of assuming one. A prompt can interpolate {{fired_at}},{{last_run_at}}, {{last_success_at}}, and whether this fire was cron or manual. If Friday’s run failed, Monday’s covers both days rather than quietly dropping Friday’s work on the floor.

An absent value reads as the word never, never as a blank — so the first run says so in words rather than reporting on an empty window. An unfilled marker is left standing rather than blanked, which means a broken prompt looks broken instead of looking finished.

Skipped when asleep, never stacked, always on the record.

A missed window is skipped, not backfilled. If the computer was asleep at 08:30, that occurrence stays missed unless the automation is explicitly set to catch up once on start. Asking, running, and collecting all happen on a computer that is on.

A slow run never stacks. If last night’s suite overruns its next occurrence, the next fire joins the one already in flight rather than starting a second. One automation never runs twice at once, so a busy computer can’t send the same report twice.

A schedule whose recipe was deleted says so loudly rather than failing quietly, and deleting a recipe is refused by name while an automation or a trigger still points at it. PRCHD does not guarantee that a report is worth reading; it guarantees that what happened is on the record.

The report is posted, not archived: it is a message in a channel rather than a document store. Token and context usage are reported; monetary cost is not.

Let the computer that has the code write the report.

The same recipe runs on demand, from Slack, from a schedule, and from a webhook, through one launcher. Write it once; fire it four ways.

Next: the same launcher, fired by a crash →On your own computer, without Slack →