Automating repetitive tasks

Identify repetitive work in your development loop and turn it into repeatable, automated workflows with the Tessl Agent.

Takeaways: After reading this page you will know how to use the find-automations skill to identify manual workflows in your repository that should be automated, how to turn findings into implementation tickets, and how to have the tessl agent build a CI workflow that runs an agent on a schedule to handle recurring work.

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. Have the tessl agent build the automation as a CI workflow
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.

Prefer your own coding agent? Install the plugin with tessl install tessl/harness-engineering and the skill becomes available there too. The rest of this tutorial assumes the tessl agent.

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: Build the automation

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

Recurring chores

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

For tasks that require judgment — writing changelog entries, reviewing code, updating documentation — 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 4: 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. Ask the tessl agent to schedule it:

Set up a weekly GitHub Actions job that runs find-automations over the last 7 days and saves the candidate list where the team can review it.

The agent runs find-automations headlessly with tessl launch skill find-automations --agent tessl-agent on a weekly cron plus workflow_dispatch, and uploads the findings as an artifact for the team to review. Adjust the cadence and the output destination to fit your team.

Review the weekly artifact. When candidates appear across multiple weeks, escalate them to tickets. This prevents the backlog of manual chores from growing quietly.

Next steps

• 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 Setting up agentic code review and tessl change verify to enforce structural invariants automatically so reviewers don't have to leave the same comment repeatedly.
• Combine both scans into a single scheduled workflow that runs both skills and aggregates their findings.