Designing a Morning-Briefing Routine With a Real Review Path

1. Trigger and access:

A Scheduled trigger set to the Daily preset at 7am — times you enter in the web form or via /schedule are interpreted in your local timezone and converted automatically, so the routine fires at 7am wall-clock time regardless of where the cloud infrastructure actually runs. (A weekdays-only cadence isn't one of the built-in presets, so this would need /schedule update to set a custom cron expression, or the routine prompt itself could check the day and skip weekends — the former is cleaner since it avoids burning a run on Saturday/Sunday at all.) The routine needs the repository (or repositories) whose issues and PRs matter, and a Slack connector to post the summary. It does not need broad network access — the default Trusted environment is sufficient since GitHub and Slack access both route through connectors/GitHub cloning rather than arbitrary outbound requests.

2. The saved prompt:

Post a morning briefing to #eng-standup covering three sections:

1. New issues opened in this repository since your last run (use the
   issue creation timestamp; if this is the first run, cover the last
   24 hours). List title, author, and a one-line summary of each.
2. Open pull requests with no review activity (no comment, no review
   submitted) more than 3 days after opening. List title, author, and
   days open.
3. A one-line status for last night's CI runs on `main`: all green,
   or which workflow(s) failed and a link to the failed run.

If a section has nothing to report, say so explicitly rather than
omitting the section ("No new issues since last run.") — always post
all three sections, every run, even when everything is empty or green.
If you cannot determine something (e.g. CI history isn't accessible),
say exactly what failed and why instead of guessing or skipping it.

The "self-contained" requirement here is doing real work in two places: it defines what "since the last run" means precisely enough that Claude doesn't have to guess a window, and — critically — it forces the routine to post something every single run, including an explicit "nothing to report," rather than silently posting nothing when there's nothing notable. Since there's no human present to ask "wait, did this actually run?", the prompt itself has to remove that ambiguity.

3. The review path:

The always-post-all-three-sections instruction from part 2 is itself the first layer of observability: because the routine posts on every run, a genuinely missing post is now a real signal (something broke) rather than an ambiguous one (maybe there was nothing to report, or maybe it crashed). Beyond that, the honest habit is to periodically — not necessarily every single morning, but on a cadence, and definitely the first time a post looks thin or wrong — open the actual run and read the transcript, since a green run status only confirms the process exited without an infrastructure error, not that the content was correct. Asking directly, conversationally, "why did this morning's briefing look off?" reads the run log and surfaces tool errors, permission denials, or a connector that silently stopped authenticating — none of which a status dot alone would reveal. The failure mode specifically worth testing once, deliberately, before trusting this in production: does the routine still post on a morning with zero new issues, zero stale PRs, and all-green CI? If posting only happens when there's "something to say," a silently broken routine and a genuinely uneventful morning look identical from the outside.