Put recurring work on a schedule. Review what comes back.
Describe the recurring job in a Session — the Monday dependency sweep, the nightly docs re-sync. Echelar drafts the Automation with its schedule, scope, and checks. It stays disabled until an owner or admin turns it on, and when the work changes code, it comes back as a pull request.
How a schedule is set up
- 01
Describe the recurring job in a Session, in plain English.
- 02
Echelar drafts the Automation: schedule, scope, checks, and where the result goes.
- 03
An owner or admin reads the draft and enables it. Every draft lands disabled.
What a scheduled Automation does
- Run on the schedule you set
- Weekdays at 08:00, nightly, monthly — the Automation starts on time and does what you authored, inside the repositories in its scope.
- Hand back a pull request
- When the work changes code, the result is a focused pull request on the repository it belongs to, waiting for your team.
- Leave an audit record
- Every fire writes a record with the match trace and the exact prompt it sent. Versions are kept, so a change can be rolled back.
What it cannot do
Limits are part of the integration, not a setting. The security page covers where code runs and who can enable what.
- Enable itself, or change its own definition without a person.
- Merge anything.
- Act outside the repositories and scope in its definition.
Bring the real one.
One repository, connected live, in thirty minutes with the founder.