Automations

Automations run a prompt on a schedule: hourly, daily at an hour, or weekly. Each automation targets a project with its own provider and optional model, and can be paused with a toggle. Run now fires one immediately. Runs appear as threads, so scheduled work is as inspectable as interactive work.

A finished thread can be repeated rather than retyped: put its prompt on a schedule as a new automation, or distill the run into a Build workflow when the shape of it is worth keeping.

Use Edit to change an automation in place. Its recent runs link to the corresponding transcripts, including live and quota-wait runs. Changing a name, prompt or model keeps the schedule's identity; changing the schedule recalculates its next run. History retention removes completed old runs, preserving unfinished work.

You can also describe an automation in a thread. The agent creates it and a card links to it with Open in Automations.

Instead of a schedule, When can be an event. The app polls for these about once a minute:

• GitHub: PR opened, PR merged, Label added (optional label filter), Review submitted, Push (optional branch), CI completed (optional branch and result), and Issue opened. Use triage template fills in an issue triage prompt that labels, dedupes and questions new issues, so only well-formed ones reach plan:todo.
• Linear: issue created or status changed, optionally per team or status.
• Sentry: a new grouped issue. Save an auth token in Settings, Git, or set SENTRY_AUTH_TOKEN.

Each automation has a Memory field: notes it keeps between runs, which a run replaces by ending with an <automation-memory> block. After three failed runs in a row the automation pauses itself and notifies you. Turning it back on resets the count.

Scope chooses Private (this machine) or Project (solenta.json). A project automation is written to solenta.json so teammates get the definition, but it only fires on a machine where someone chose Run on this machine and approved the file.