Security review is the clearest candidate for a routine. It matters every week, it is easy to postpone, nobody complains when it slips, and its value comes almost entirely from noticing what changed.
It is also the routine most people build wrong, in the same way: they give it too much access and too little definition.
Here is the version that works, read-only from end to end.
What you are building
A routine that runs every Monday morning, reads the repository through approved GitHub tools, and returns at most five findings introduced or materially changed since the previous Monday — each with a file path, a severity, and a recommended action.
It does not fix anything. It does not open pull requests. It reads, ranks, and reports.
Step 1: connect GitHub read-only
Connect GitHub from Connections. Then, from the routine, discover tools and enable only what a review needs: repository contents, commits or pull requests in the window, and security findings if you have them.
Every discovered tool arrives disabled, so this is a matter of enabling a handful rather than restricting a default. Leave every write tool alone — no branch creation, no pull requests, no issue comments.
Two boundaries are better than one: if you can, point the connection at a credential that has no write access at all. A tool policy is enforced by us; a read-only credential is enforced by GitHub.
Step 2: define the window absolutely
The single most common defect in a recurring audit is a floating definition of "recent." The model resolves it differently on different weeks and the output quietly stops being comparable.
Write it as something resolvable — "changes merged since the previous Monday" — and require the routine to state the window it used in the result. When week nine looks strange, the first thing you check is whether the range moved.
Step 3: write the instruction as a standing responsibility
Audit {{repository}} for security risk introduced or materially changed since
the previous Monday.
Produce at most five findings, ranked by severity. Each finding states:
the file path, what changed, why it matters, and a recommended action.
Every finding cites a file path or a commit. If something looks risky but
cannot be confirmed from the repository, list it under "Unverified" rather
than omitting it or asserting it.
Read only. Do not modify files, open pull requests, or contact anyone.
Do not restate long-standing issues unless they changed this week.
If nothing relevant changed, say so in one line. Do not find something to
report.Put the repository in a variable so the same instruction serves every repo you audit.
The last paragraph is not decoration. A model asked to find problems will find problems; explicitly permitting a quiet week is what stops the routine from manufacturing findings.
Step 4: schedule it for when it will be read
0 9 * * 1 in your team's timezone. A brief that lands Monday morning gets
acted on. The same brief at 16:00 on Friday does not.
Schedules are evaluated in the routine's IANA timezone, so it stays at 09:00 local across daylight-saving changes.
Step 5: prove it once, by hand
Run it manually before you activate. Then read the trace rather than the result.
Three questions:
- Did it read the window you asked for? Look at the tool call arguments, not the prose. An audit that concluded without fetching the diff is an opinion.
- How close to its time budget did it get? A run that finishes at the edge of its deadline will fail the week the diff is larger. Extend the deadline or narrow the scope.
- Would you act on this? If the findings are technically correct and practically useless, the instruction needs a sharper definition of severity, not a better model.
Only after a successful manual run can the schedule be activated. That gate is the whole point: the version that runs unattended is a version somebody read the output of.
Tuning after a month
It repeats itself. Add an explicit instruction to mark each finding as new, unchanged, or resolved. The routine cannot see previous runs, so tell it what the prior state was through a variable, or accept that "new" means "new in the diff window."
It is too noisy. Lower the cap. Five findings that get fixed beat forty that get skimmed.
It hits its deadline. Large repositories need a narrower scope — one service, one directory — rather than a bigger budget. Two focused routines outperform one that runs out of room.
You want it to fix things. That is a different routine, and it deserves its own deliberate grant. The shape that works is one that opens a pull request and stops: a change a person reviews, with the audit's evidence attached. Keep the read-only audit as it is and add the second routine beside it, rather than widening this one's permissions.
Why read-only is the right starting point
You will learn more in four weeks of read-only runs than in any amount of planning: which tools it actually reaches for, how it interprets severity, where its evidence is thin. That is the information you need before deciding what it may change.
Autonomy is easy to add later and awkward to take back.
The full walkthrough, including tool discovery and permissions, is in Weekly security audit.