Prepare an existing repository so Tessl agents and Tessl Code Review work well in it: better agent context, verifiers, Code Review lenses, and lint rules drawn from how the team already works. Use when someone wants agents to make fewer mistakes in their repo, wants to prepare or improve their repo for agents, or wants to turn recurring review feedback into checks.
85%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Low
Low-risk findings worth noting
The canonical home for this skill is tessl-labs/factory-setup
This skill looks at how a repository is built, reviewed, and fixed, and proposes changes that help agents get work right the first time. Each proposal is a rule the team already follows, placed where it is enforced best: a lint rule or test, a verifier, a Code Review lens, or agent context.
It works on its own, or as a next step after factory-setup once the first
automation is live.
Rules for the whole session:
Run the checks in factory-setup step 2
that apply here: the Git repository and GitHub remote, tessl.json,
git status for uncommitted changes, tessl whoami, and the GitHub repo and
its default branch. Stop where those checks stop.
Then fetch the default branch and compare HEAD with
origin/<default branch>. Steps 1 to 5 read the checked-out files, and step 6
branches from origin/<default branch>. When they differ, tell the user and
ask them to switch to an up-to-date default branch before you go on.
Read before you ask:
AGENTS.md, CLAUDE.md, rules, skills, and
anything tessl.json installs.tessl code repo view <owner/repo> --json. Note
whether repository.review.enabled is true. If the command fails, for
example because the user is in several organizations without TESSL_ORG
set, Code Review is not available for the organization, or the repository
is not selected for the GitHub App, treat Code Review as off, tell the user
in one line, and continue without the lens tier.Tell the user what you found in two or three sentences and ask them to correct it.
Then check the skills this needs: tessl-verify, and
create-code-review-lens only when item 4 found Code Review on. In Claude
Code and Cursor they install as tessl__<name>, so match either name. If any
are missing, ask once, in one question, whether to install only the plugins
for the missing skills (tessl/tessl-verify for tessl-verify,
tessl/code-review for create-code-review-lens) for their account with
tessl install -g <plugin>, which leaves the repository unchanged. After the
install, confirm each skill is visible; if an install fails or a skill is
still not visible, say so in one line. A skill that is still missing, because
the user declined, the install failed, or it is not visible after the install,
makes its tier's items "needs " items, shown but not applied, as
the proposal list says. Tell the
user this once.
Collect where agents and reviewers keep tripping, from the sources in evidence. Each source is optional; skip one that is missing and say so.
Turn the evidence into candidate rules, each one a thing the team already expects and can name. Follow routing.
Give each candidate one tier, following routing:
Show the routed proposals, grouped by tier, each with its evidence in one line, following the proposal list. Lint and test proposals come first, and "needs " items stay in their tier's group; both are unnumbered, with no yes or no choice, and are never applied. Only the other items are numbered. Ask which to apply; if there are none, or the user picks none, stop.
Make the picked changes on one new branch, following apply. Write each tier's files from its step 6 sections:
Run each new verifier and lens on a few historical pull requests, following the step 7 sections:
Each count, sample, and backtest run spends credits; lint and dry-run
commands are free. Decide warn or an exclude list per verifier before
counting, skip a full count that cannot change a level, and ask once for one
plan with a firm total, as
apply says. Tell the
user each one's catches, false alarms, and the replays that did not exercise
it, which replays used the merged result, and whether its backtest was weak.
Drop or fix the ones the user
rejects; a dropped verifier or lens is deleted. Then check the configuration
and commit, one commit per category, as
apply says.
Follow the step 8 sections of apply:
Use the marks and format from the factory-setup timeline, under the heading "Preparing your repository", with these stages:
fkukuck/fabro
ac667f5
Canonical home
since Oct 15, 2026
Also appears in
last in sync Oct 22, 2026
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.