A suite of focused code-review skills for Tessl Agent and GitHub Actions review workflows (`tessl change review`). Each review lens is its own skill, so a workflow can invoke one lens or several. Fork and tune any skill for your own repository.
80
100%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
A suite of focused code-review skills for use from Tessl Agent and GitHub
Actions review workflows via tessl change review. Each review lens is its own
skill, so a workflow can point at exactly the lenses it wants instead of
activating all of them.
This plugin is private for now. It is designed to be easy to fork: copy a skill into your own repository and tune its triggers, anti-patterns, and examples for your codebase.
tessl change review takes one or more --skill references. A reference can be
a local path (a SKILL.md file or a skill directory), an installed skill name,
or a registry ref workspace/plugin[@version]#skill. Pass only the lenses you
want — skills are not auto-discovered.
Run a single lens against the current diff (local path):
tessl change review \
--skill apps/cli/plugins/code-review/skills/review-security-risksRun two lenses together:
tessl change review \
--skill apps/cli/plugins/code-review/skills/review-security-risks \
--skill apps/cli/plugins/code-review/skills/review-test-riskOnce the plugin is installed, reference a skill by registry ref:
tessl change review --skill tessleng/code-review#review-contract-boundariestessl change review only emits structured review data; a GitHub caller posts
it as an overall review plus inline comments. In a workflow step, select the
lenses relevant to the changed paths and write the result to a file:
tessl change review \
--skill tessleng/code-review#review-security-risks \
--skill tessleng/code-review#review-contract-boundaries \
--base origin/main \
--json --output review.jsonThen post review.json from a later step. Because each lens is a separate
--skill, a workflow can choose lenses per changed path — for example, run
review-contract-boundaries only when an API schema or migration changed.
Add skills/<name>/SKILL.md with name and description frontmatter, a short
single-screen body stating the review stance, what to look for, and how to
report. Keep findings high-confidence and file-anchored, review the diff first,
avoid broad repository archaeology, and prefer concrete findings over generic
advice — say so explicitly when no issues are found.