Docs that stay true to the code

An automation with a GitHub trigger on pull_request_merged and a prompt like “check the merged change for docs that now lie and fix them”. Each run is a normal Capy thread that gets the prompt, the merged pull request as context, and a machine to work on.

Whatever describes the change: READMEs, API docs, code comments and changelogs. The run opens a pull request with its edits, so you review them like any other change.

Yes. GitHub triggers take conditions on repositories, branches, authors and labels, and a run_when sentence such as “the change touches a public API” filters the rest. A fast model checks each event against it, and you aren’t billed for that check.

Write them in AGENTS.md: the root file for every thread, a nested file for one package, or a glob rule for a file type like **/*.mdx. Put a longer procedure, such as a release-notes checklist, in a skill in your repository or in Drive.

Yes. Documentation gaps are part of the Maintainability category, so a review can flag a pull request that leaves its docs behind, on the file and line. When Capy opened the pull request, its thread triages the finding.

Add a schedule trigger, a five-field cron in your timezone, with a prompt to backfill what is missing or stale. If the scheduler falls behind, missed runs coalesce into one rather than a backlog.

By default, yes. In single thread mode the automation keeps one standing thread that holds its machine and context across runs, and the automation’s own Drive scope keeps state between runs.

Every automation runs as one principal, the person who saved it or a service user an admin picked, and commits attribute to it. Use a service user for anything long-lived, since its automations keep running after people leave.