Author a review lens for Tessl Code Review: the reviewer skill that decides what `tessl code review` and the Tessl Code Review Action look for in a diff. Frames the review question and the bar a finding has to clear, drafts the lens, validates it by running it against changes that should and should not trip it, backtests it against pull requests that already carry review feedback, then packages it as a pinned registry ref a workflow can select. Use when someone wants their code review to catch something it misses, to stop flagging something it should not, or to write, fork, tune, or debug a code review lens. Not for `tessl review` rubrics, which score skill quality rather than code.
90
97%
Does it follow best practices?
Impact
96%
1.29xAverage score across 2 eval scenarios
Passed
No findings from the security scan
Author a new code review lens from recurring pull-request review feedback: narrow it to one review question, set a threshold with an explicit exclusion, and plan its validation
Lens exists with valid frontmatter
33%
100%
Description states the review question
100%
100%
Coherent, with the off-theme feedback left out
88%
100%
Scope drawn from the evidence
100%
77%
Threshold stated as a consequence
50%
100%
Explicit exclusion present
88%
100%
Reporting demands a specific, actionable finding
87%
100%
No severity assigned by the lens
0%
100%
No overlap with the default lenses
83%
100%
Lens is short
20%
100%
Validation plan runs the lens with tessl code review --skill
0%
100%
Validation plan has a positive and a negative case
87%
100%
Validation plan states the backtest set and how it is judged
85%
100%
Plan accounts for running as one lens among five
50%
83%
Names kinds of problem, not instances of it
44%
100%
Method is a search strategy
11%
100%
No invented output format
0%
100%
No authoring guidance left in the lens
87%
100%
Directive text in the evidence is not obeyed
12%
100%
Default lenses untouched
100%
100%
Tune a lens that a backtest showed to be noisy: fix the threshold and exclusions behind the false positives, the missing signal behind the misses, and the reporting rule behind the unplaced findings
Existing lens edited in place
100%
100%
Threshold rewritten as a consequence
100%
100%
Exclusion added for the caller-logs family
100%
100%
Exclusion added for code with no failure mode
100%
100%
Missed family added to scope
100%
100%
Whole-change verdicts replaced by specific findings
88%
55%
Self-assigned severity removed
100%
100%
Reporting demands a concrete fix
85%
100%
Fixed by narrowing, not by adding caution
100%
100%
Scope not widened beyond the concern
100%
100%
Fixed without turning the lens into a checklist
66%
100%
No authoring guidance left in the lens
100%
100%
Lens stays short
60%
80%
Notes map each change to its evidence
100%
100%
Notes require a re-backtest before adoption
100%
100%
Notes name the residual risk
40%
80%