Lesson 7 — Repo autopilot with Tessl Agent

Everything so far in this course waited for you to act. The review eval scored a skill when you ran it; the CI gate blocked a bad PR when someone opened one; the optimizer improved a skill when you asked. This lesson is the always-on layer above all of them: connect a repo to Tessl Agent and it reads the trail your work already leaves — PR review comments, CI results, session logs — for the corrections that keep recurring, then opens improvement PRs so the same mistake stops coming back.

The surprising part is what it fixes. Tessl Agent does not write your application code. It fixes your context and environment: a new rule, a sharper skill, a verifier that catches the mistake next time. Patching one PR by hand fixes today; fixing the context is what stops the pattern from recurring at all.

What you'll build

By the end you'll have:

• A repo connected to Tessl Agent through the GitHub App.
• A recurring correction pattern the agent surfaced from your real PR and CI history.
• An improvement PR — a change to your rules, skills, or verifiers — that you reviewed and verified against an eval.

You still approve. Autopilot means the agent proposes the work, not that it merges unreviewed. Every PR it opens is something you read and accept, send back, or drop, exactly as you would a teammate's.

Connect the repo

Connecting is a one-time integration you set up in the registry, not a CLI command. The agent needs the Tessl GitHub App installed so it can read a repo's PR and CI history. In the registry:

1. Go to the Tessl Registry at https://tessl.io/registry and log in.
2. Select your workspace from the selector in the left menu.
3. Click Integrations.
4. Select Enable Integration.
5. Next to the organization you want to add the app to, select Configure.
6. Choose whether to authorize Tessl on specific repositories or on all of them.
7. Click Install & Authorize.

When it succeeds, the integrations screen shows Connected for that organization:

Integrations
  your-org   ✔ Connected

Scope it deliberately. "Only select repositories" is the safer first choice: connect one repo, see what the agent proposes, then widen access from the Tessl app's GitHub settings once you trust the flow. You can change the repository list there at any time.

Surface a pattern, then review the fix

With the repo connected, point the agent at your recent history and ask it for the pattern. The find-optimizations skill reads PR review comments, review summaries, and CI results to find where agents kept needing the same correction:

Look over PRs from the last 2 weeks and tell me the pattern.

It returns findings grouped by what would fix each one — rule, skill, verifier, or refactor — with evidence linking back to the specific PRs:

3 recurring patterns found
  1. [rule]     Migrations not flagged in PR bodies      evidence: #1189, #1201, #1218
  2. [skill]    Commit messages miss the type prefix      evidence: #1174, #1190
  3. [verifier] Error paths land without a test           evidence: #1205, #1212

Pick one and turn it into work. The agent files it and drafts the fix as a change to your context, not to your application code:

Create a ticket from item 2.
Implement the fix from item 1.

The fix arrives as an improvement PR. Review it the way you would any teammate's: read the diff, check it targets the right context, and confirm it addresses the pattern before you merge.

Verify the loop

Prove the fix does its job. Generate eval scenarios from the very PRs that exposed the problem and run them with and without the change:

Generate eval scenarios from PRs #1189, #1201, and #1218, then run the eval with and without my new context.

Then walk four checks:

• The registry integrations screen shows Connected for your organization, and the agent can read the repo's history.
• A find-optimizations run surfaced at least one recurring pattern backed by evidence: specific PRs, not a guess.
• The agent opened an improvement PR that changes your context (a rule, skill, or verifier), not your application code.
• The eval built from those PRs passes with the new context where it failed without it.

If nothing surfaced, the connected repo may not have enough PR or CI history yet for a pattern to show; point the agent at a longer window. If the PR patches application code instead of context, it hasn't fixed the recurrence, so send it back toward a rule, skill, or verifier.

What you keep

You connected a repo, let the agent read its real history for a recurring correction, and turned that pattern into a durable fix to your context that you reviewed and verified. The gate and the optimizer still do their jobs on demand; Tessl Agent adds the layer that watches over time and proposes the long-tail cleanup no one else gets to. You approve every change, and each one makes the next class of mistake less likely.