#Automating repetitive tasks

Every repository accumulates manual chores: the same kind of dependency update PR every week, a maintainer who manually applies the same changelog format to every release, a reviewer who leaves the same comment about a missing label. These are automation candidates. The find-automations skill reads your PR history to surface them.

#The core workflow

1. Run find-automations to identify manual workflows in your repository
2. Review the numbered list of automation candidates
3. File tickets for the ones worth building
4. Choose a hosted loop or a CI workflow, and have the tessl agent build it
5. Run find-automations on a schedule to catch new candidates as they emerge

#Prerequisites

• Tessl installed and initialized (tessl init)
• Authenticated (tessl login)
• gh CLI installed and authenticated (for reading PR data)
• Access to a workspace

#Step 1: Find automation opportunities

The find-automations skill reads recent PR history to identify manual workflows, recurring chores, and coordination patterns that could be automated.

The tessl agent ships with the tessl/harness-engineering plugin pre-bundled, so find-automations is available without installing anything.

Ask the agent to run it:

Run find-automations on this repo and show me the candidates.

The skill inspects the last 90 days of PR history. For each candidate it finds, it produces a structured output entry. A typical output looks like this:

Summary: Found 4 clear automation candidates across 3 months of PR history.

1. Title: Automate weekly dependency updates
   Summary: The same contributor opens a dependency update PR every Monday morning.
   Pattern Type: established
   Why Automate: Predictable, low-judgment, repeating chore.
   Evidence: PRs #1180, #1190, #1202, #1215, #1223 — all titled "chore: update deps",
             all opened by @alice between 9am and 10am UTC on Mondays.
   Suggested Execution Mode: scheduled
   Suggested Trigger: Weekly on Monday morning
   Manual Trigger: none
   Implementation Direction: Run npm outdated, apply compatible updates, run tests,
                             open a PR if anything changed. Skip major bumps.

...

The skill is read-only. It does not modify any files, create commits, or open issues.

#Step 2: File tickets for the candidates

Review the numbered list and pick the candidates worth building. The tessl agent can create the tickets directly — refer to findings by number:

Create a ticket from item 1.

For each ticket, the agent includes the evidence, the suggested execution mode, and the implementation direction from the finding. This gives the implementer enough context to act without re-running the analysis.

The tessl agent builds up memory about how you like to create and assign tickets — which issue tracker you use, how you format titles, who things get assigned to. It records this under .tessl/memory/preferences/ (run /setup-memory if it has not been initialized yet), so after the first ticket you rarely have to repeat yourself.

#Step 3: Choose where the automation runs

Each finding suggests a trigger, such as a weekly cron or a labeled issue. Decide where it runs before you build it:

• A hosted loop runs in Tessl's cloud. You declare an action and its trigger in tessl.json (an event, a schedule, or both), push to your default branch, and Tessl runs it. There's no workflow file or runner to maintain, and every run is listed on the project's Loops tab. Choose this for agent work that starts from a GitHub or Linear event or a cron. See Automations.
• A CI workflow runs in your own pipeline. Choose this when the work must gate a pull request as a required check, needs your build cache or private network, or belongs inside an existing release workflow. Mechanical chores that need no agent, such as applying a label, also stay in CI.

#Step 4: Build the automation

Each finding includes an implementation direction. Ask the tessl agent to build it, and say which you chose. It uses its workflow-automator skill to classify the task, create any plugin it needs, and write the tessl.json schedule or the workflow. It runs the underlying commands and reports them back; you stay in control of the design decisions.

#Hosted loops

For agent work that runs on a schedule, ask for a loop:

Build the dependency-update automation from item 1 as a Tessl loop: create a plugin that applies compatible updates and opens a PR, and run it every Monday morning.

The agent creates the plugin and adds a schedules entry that runs it, then validates the file with tessl schedule validate. The loop starts once the change reaches your default branch. The run needs an environment with pull-requests or write GitHub access if the plugin opens pull requests.

For a loop started by a GitHub or Linear event, declare the action and its trigger in tessl.json yourself. Declare a loop in tessl.json and Event triggers show how. Then check the file with tessl doctor --automations. If the work must run in your pipeline instead, build it in CI as described below.

#Recurring chores in CI

For purely mechanical tasks — applying a label, posting a comment, running a script — no agent is needed at runtime. Ask the tessl agent to set up a standard GitHub Actions workflow:

Build the stale-PR automation from item 3 as a scheduled GitHub Actions workflow.

The agent wires a plain Action (for example, actions/stale) on a daily schedule. The settings it chooses — the stale label, the inactivity window, the message — come straight from the finding's implementation direction, and you can adjust any of them.

#Agent-driven tasks in CI

For tasks that require judgment and must run in your pipeline, such as writing changelog entries on release-branch pushes, the automation runs an agent headlessly with tessl launch skill.

tessl launch skill <skill> --agent <agent> is the entrypoint for agent workflows: it runs an installed plugin skill through an agent in a CI environment, with per-run inputs passed via a short --instructions string. The --agent flag selects the backend.

The pattern is:

1. Create a plugin that encodes what the agent should do
2. Run the plugin with tessl launch skill in a CI workflow

Ask the tessl agent to do both:

Build the release-notes automation from item 2: create a plugin that generates a formatted changelog block, then run it from a GitHub Actions workflow on release-branch pushes.

As it works, the agent runs the relevant CLI commands and names what it creates:

• tessl plugin new — scaffolds the plugin and skill (reference)
• tessl plugin lint and tessl review — validate the plugin and skill (reference)
• tessl plugin publish — publishes it so CI can install it (reference)
• tessl install — installs the plugin in the workflow (reference)
• tessl launch skill <skill> --agent tessl-agent --yolo — runs the skill headlessly in CI

The defaults the agent chooses for the workflow, and how you might change them:

• --agent tessl-agent — the workflow runs the Tessl built-in agent. The tessl agent is particularly good at harness and repo-maintenance tasks like these. For automations that build product features, you may prefer a coding agent backend (claude-code, codex, cursor); pass it to --agent instead.
• --yolo — lets the agent apply edits without prompting, which a headless CI run requires.

#Step 5: Run find-automations on a schedule

As your repository grows, new patterns emerge. Set up a weekly scan so new automation candidates surface before they become entrenched manual chores. This is a good first hosted loop. Ask the tessl agent to schedule it:

Add a weekly Tessl schedule that runs find-automations over the last 7 days.

The agent adds a schedules entry to tessl.json that runs the tessl/harness-engineering plugin's find-automations skill every week. If you'd rather keep it in CI, ask for a GitHub Actions job instead: the agent runs tessl launch skill find-automations --agent tessl-agent on a weekly cron plus workflow_dispatch. Adjust the cadence to fit your team.

The scan stays read-only: it writes no files, posts no comments, and opens no issues. Each run returns the candidate list in its output, which you read from the loop's page or the CI job log. When candidates appear across multiple weeks, escalate them to tickets as in Step 2. Building any of them is a separate, deliberate step, as in Step 4. This prevents the backlog of manual chores from growing quietly.

#Next steps

• Turn on Learn from past work to have Tessl record recurring problems in your factory's pull requests and runs as findings, and triage them into tickets.
• Use Improving agent code quality and the find-optimizations skill to find recurring patterns in PR review feedback that suggest improvements to skills and rules, not just workflows.
• Use Tessl Code Review for pull request findings, and add tessl change verify separately to enforce structural invariants automatically.
• Combine both scans into a single scheduled workflow that runs both skills and aggregates their findings.