CtrlK
BlogDocsLog inGet started
Tessl Logo

review-and-refactor

Review and refactor code in your project according to defined instructions

70

0.98x
Quality

64%

Does it follow best practices?

Impact

96%

0.98x

Average score across 3 eval scenarios

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./.github/skills/review-and-refactor/SKILL.md

The canonical home for this skill is review-and-refactor in github/awesome-copilot

SKILL.md
Quality
Evals
Security

Quality

Content

65%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is a brief, instruction-only skill that stays lean and benefits from concrete path pointers, but its workflow stops short of a real validation loop and its task steps leave execution details unspecified. It is functional as a directive but would fail on projects without tests or without the referenced instruction files, with no guidance for those cases. Tightening step 1 and adding failure handling would raise both actionability and workflow clarity.

Suggestions

Split step 1 into distinct steps — read instruction files, then review code, then refactor — and add a feedback loop: if tests fail after refactoring, revert or fix before finishing.

Specify how to verify (e.g. the project's test command or how to detect it) and what to do when '.github/instructions/' or tests are absent, so the skill is executable in any project shape.

Trim the 'Take a deep breath' phrase and the role paragraph; both consume context without adding instructional value.

DimensionReasoningScore

Conciseness

The body is short and mostly lean — concrete file paths and directives with no concept explanations Claude already knows. Minor trimmable padding remains: the 'Take a deep breath' preamble and the 'senior expert software engineer' role paragraph are tokens that add no instructional value. This is anchor 4 ('efficient; minor instances of over-explanation that could be trimmed') rather than 5, where every token earns its place.

4 / 5

Actionability

There is some concrete guidance — exact paths ('.github/instructions/*.md', '.github/copilot-instructions.md') and a clear no-file-splitting constraint — but key execution details are missing: how to run the tests, what to do if no instruction files exist, and what kinds of refactorings are in scope. This matches anchor 3 ('some concrete guidance but incomplete... missing key details') rather than 4, which expects mostly executable guidance with only minor gaps.

3 / 5

Workflow Clarity

A rough sequence exists (read instructions → review code → refactor → verify tests), and a verification checkpoint is mentioned ('ensure they are still passing'), but there is no feedback loop for what to do when tests fail, and step 1 bundles reviewing instructions, reviewing code, and refactoring into a single item. This matches anchor 3 ('steps listed but validation gaps; checkpoints missing or implicit'), whose example likewise ends with an unelaborated test step.

3 / 5

Progressive Disclosure

The skill is well under 50 lines with no need for external references (no references/, scripts/, or assets/ bundle exists), and it is organized into clear 'Role' and 'Task' sections. Per the judging guidelines, a short skill with no external-reference need can score 5 with just well-organized sections, which this meets.

5 / 5

Total

15

/

20

Passed

Description

46%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description has a clear, concise 'what' but completely lacks 'when to use' trigger guidance, and its phrasing is broad enough to collide with many other code-related skills. It reads as a generic capability statement rather than a skill description that would reliably fire for the right task. Adding an explicit trigger clause and a few natural synonyms would materially improve it.

Suggestions

Add an explicit trigger clause, e.g. 'Use when the user asks to review, clean up, or refactor code, or to apply project coding standards found in .github/instructions/.'

Include natural synonyms users would actually say ('clean up code', 'code quality', 'coding standards') to broaden trigger coverage and reduce misses.

Narrow the scope to what distinguishes this skill — e.g. referencing the project's defined instruction files (.github/copilot-instructions.md) — so it does not overlap with generic code-review or cleanup skills.

DimensionReasoningScore

Specificity

The description names the domain ('code in your project') and two concrete actions ('Review and refactor') plus a scope qualifier ('according to defined instructions'), but coverage is not comprehensive — it never says what kind of instructions or what the output looks like. This matches anchor 3 ('names domain and 1-2 concrete actions, but not comprehensive') rather than 4, which expects several specific actions with only minor gaps.

3 / 5

Completeness

The 'what' is clear (review and refactor code per project instructions), but the 'when' is entirely absent — there is no 'Use when...' clause or equivalent trigger guidance, which per the judging guidelines caps completeness at 3. It is not a 2 because the 'what' half is concrete rather than vague.

3 / 5

Trigger Term Quality

'Review', 'refactor', and 'code' are relevant natural keywords, but common variations users would actually say — 'clean up code', 'code quality', 'lint', 'apply coding standards', file types — are absent. This fits anchor 3 ('some relevant keywords but missing common variations or synonyms'), not 4, which requires good coverage with only a few missing terms.

3 / 5

Distinctiveness Conflict Risk

'Review and refactor code in your project' is very broad and would overlap heavily with any code-quality, cleanup, or review skill; almost any code task could match it. This matches anchor 2 ('very broad; high overlap risk with many similar skills') — it is more specific than anchor 1's pure genericity, but lacks the narrowing triggers needed for anchor 3.

2 / 5

Total

11

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
trackdubllc/Babel-Player-Alpha
Reviewed

Table of Contents

Is this your skill?

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.