Automate work

Automation should make an understood workflow repeatable. Begin with a manual task, such as “Summarize the open release blockers for this project,” and define the expected context before relying on an automated workflow.

Before you begin

Have a project, a bounded prompt, an owner for failures, and a clear rule for what should not create work. Use only information that is appropriate for the project's approved access controls.

Automation is project-scoped. If New task says Create a project first, create and verify a project before looking for the Automation area. The demo workspace currently has no project, so project-scoped automation screens cannot be captured there without changing production state.

Install an Automation Template

  1. Open the target project, choose Automation, and select Add template.
  2. Choose an available template and review the repository, connection, notification group, and other requirements shown for it.
  3. Complete the configuration. For Issue watcher, select Preview query; for Rescue CI, select Preview required workflows. Resolve every validation or connection message before continuing.
  4. Review the preview, then select Install template. A template without an available Install template action cannot be installed.

Workspace Viewers can inspect templates, configured installations, status, and history. A Workspace Operator or another member with equivalent permission is required to install, update, pause, resume, retry, or uninstall a template. Selecting a repository or connection never grants access beyond the selected project's existing permissions. When the same project and repository already have GitHub event automation, use the exact GitHub connection that established that automation target; choosing another active connection can fail during installation even when preview succeeds.

Available templates

  • Issue watcher watches a bounded GitHub issue query and creates reviewable planning work only when an issue newly enters the configured results.
  • Rescue CI collects required default-branch GitHub Actions failures and creates repair-planning work for qualifying failed or timed-out workflows, including failures that do not require code changes.

Both templates are configured from the project’s Automation page and require a current preview before installation. Their repository and GitHub connection prerequisites remain tied to the project and selected setup; they do not grant access to anything outside that project.

Installing a template, collecting events, evaluating matches, and sending notifications do not add a Labor0 usage charge. Accepted planning work follows the ordinary task usage and pricing terms; see Pricing and usage before enabling recurring automation.

Configure Rescue CI

  1. From Add template, choose Rescue CI, enter a recognizable installation Name, then select the repository, its GitHub connection, and the group that should receive failure notices.
  2. Under Monitored workflows, add between 1 and 50 workflow file paths. Use the full path under .github/workflows/, for example .github/workflows/nightly.yml. Each path must name a unique .yml or .yaml file; folders, backslashes, and paths outside that directory are rejected.
  3. Optionally add bounded repair instructions. Do not include credentials, workflow inputs, or private values.
  4. Select Preview monitored workflows. The preview reads the repository's current default branch and confirms that every listed file is an active workflow in that repository without saving the configuration.
  5. Review the default branch and monitored workflows, then select Install template. The installation appears under Configured templates when setup succeeds.

Rescue CI accepts a failed or timed-out run only when it was started by a schedule or manually, its workflow is monitored, and its branch exactly matches the repository's current default branch. Push, pull-request, other-branch, successful, canceled, skipped, and unmonitored runs create no repair work. One workflow and commit combination creates at most one rescue episode even if the delivery is repeated or the run is retried; two monitored workflows on the same commit can create separate episodes. Manual and scheduled runs use the same rule, and manual-run inputs are not collected.

Each accepted episode opens ordinary project planning with the original run evidence and the current default-branch state. When the effective Graph-change auto-approval setting is disabled, review the proposed Graph change before approving it. When it is enabled, Labor0 can commit a validated Graph change and start newly ready work without waiting for review; confirm the committed Graph result and any newly started work. If automatic approval cannot finish, use the ordinary review warning and actions to decide the pending change. Planning may conclude that no repository change is needed when the problem has already been resolved.

To replace the monitored set, open the installation, add or remove paths, preview the complete new list, and save. The replacement applies to eligible deliveries received after the successful update; it does not backfill earlier failures or cancel existing episodes. Pause stops new episodes without canceling work already accepted. Resume rechecks access and the configured workflows before accepting new episodes.

Troubleshoot Rescue CI

  • A workflow path is rejected: enter a unique workflow file beneath .github/workflows/ with a .yml or .yaml extension, then preview again.
  • Preview cannot find a workflow: confirm that the file is active in the selected repository and that the GitHub connection can read it. Reconnect only the connection identified by the page, then retry the preview.
  • A failed run created no episode: confirm that it was a completed scheduled or manual run for a monitored workflow on the current default branch. Other run sources, branches, and conclusions are intentionally ignored.
  • The installation is paused: open its status for the stated cause, correct the workflow list, prompt, connection, or access problem, and select Resume. Existing episodes remain available while paused.

Recurring schedules

Use Schedules when the same bounded prompt should run on a predictable cadence. Select the target project, then choose Schedules from its top-level navigation to preview occurrences, create the schedule, and inspect its first run.

Expected result

The project Automation page shows the installation under Configured templates. Open it to confirm its current status, recent activity, and any available history or recovery action. Work created by a template appears through the linked project planning or task result; the installation detail remains the place to inspect template health.

Permission guidance

Automation settings are project controls. Use Workspace Viewer access for inspection and Workspace Operator access only for members responsible for configuration and lifecycle changes.

Continue in the app

Open the Labor0 app, select a project, and choose Automation.

If a template is unavailable

Symptom: a template, Install action, or expected result is unavailable. Likely cause: the template is not currently installable, your role is read-only, billing cannot start work, or a required repository, connection, or notification group needs attention. Safe recovery: confirm the selected project and visible status, reconnect or replace only the dependency identified by the page, and ask a Workspace Operator to retry. Pause or uninstall an installation when safe shutdown is needed; do not repeatedly start work while its status is uncertain.

Existing GitHub automation target: if the project and repository already use GitHub event automation, select the connection that established that target. Preview may not detect a different-connection conflict; do not substitute another active connection.