A schedule our servers run had no workspace: it read, discussed and answered, and anything that needed a checkout belonged to a Mac that had to be awake. A server schedule can now name a repository. The room reaches it through the GitHub App, the way pull-request reviews do: it lists the tree, reads files, and puts what it writes on a branch of its own as a draft pull request. No clone, no disk, and nothing executed: tests, builds and merges stay yours, or your Mac's.
Setting it up
Where to find it. Web: Settings → Schedule → Add one, Repository (shown once the GitHub App covers a repository for your account or your team). iPhone: New schedule → Repository, as owner/name.
Choose the repository and, optionally, a branch; blank reads the repository's default branch, which is also the pull request's base. The row says repository: owner/name.
What the room can do
Four tools, in every run of that schedule: list the files (a pattern narrows it), read a file as it is on the branch or as this run changed it, write a file whole or delete it, and see the run's changes so far. A run may change at most twenty files and four hundred kilobytes in all.
When the run ends with changes, they go to GitHub as one commit on letthemchat/schedule-… and a draft pull request whose body is the room's agreed answer, the files changed, and a line saying nothing was run. The schedule's last run links to it. Nothing ever reaches the base branch: the branch prefix is the one unattended Mac runs are held to.
When to use it. A weekly dependency or docs review that proposes the change rather than describing it; a release-notes draft; a triage that drafts the fix for a person to run and merge.
When not to use it. Anything that must be built or tested before it is proposed: that is a Mac schedule, with the checkout and the tools. A hosted runner that executes is not what this is.
Further reading. Git database REST API — GitHub Docs.