CtrlK
BlogDocsLog inGet started
Tessl Logo

safe-refactoring-rules

Ensures all refactoring is deterministic, behavior-preserving, and non-breaking

55

Quality

69%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./.claude/skills/safe-refactoring-rules/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

68%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 tight, well-structured set of behavior-preservation rules with concrete, specific directives and a clear scope-discipline section that prevents overlap with sibling skills. Its weakest area is workflow clarity, because refactoring is a destructive/batch operation and the skill asserts required properties without explicit validation or verification checkpoints.

Suggestions

Add an explicit validation step to the uncertainty or behavior-preservation section, e.g. 'After refactoring, run the test suite or diff observable outputs to confirm behavior is unchanged before finalizing.'

Include one worked before/after refactoring example to lift actionability from mostly-executable to copy-paste ready.

Trim the redundancy in section 7 (three sentences restating 'reuse existing abstractions') and drop the Purpose re-statement of the three qualities already in the description.

DimensionReasoningScore

Conciseness

The body is lean, bullet-driven, and assumes Claude's competence with no padding or concept explanations, but the Purpose section restates the description's three qualities and section 7 repeats the reuse idea three ways, leaving minor trims that keep it just below a 5.

4 / 5

Actionability

Rules are concrete and specific with actionable directives and embedded examples (e.g. 'Never replace dependency injection with service locators (`app()`, `resolve()`)'), but there are no worked before/after examples that would make the guidance copy-paste ready, so it lands at mostly-executable rather than fully.

4 / 5

Workflow Clarity

Section 6 supplies a clear if/then sequence and section 9 an ordered priority list, but for an inherently destructive/batch operation like refactoring there are no explicit validation checkpoints (e.g. 'run tests', 'verify behavior unchanged'); only implicit property assertions, which per the destructive-operation cap holds workflow clarity at 3.

3 / 5

Progressive Disclosure

The content is well-organized into cleanly separated numbered sections with clear headers, and cross-skill references (application-architecture-standard, data-layer-contracts) are named in prose, but with no bundle files there is no file-level one-level-deep reference structure, so it sits at good-structure-with-minor-gaps rather than a 5.

4 / 5

Total

15

/

20

Passed

Description

53%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 is concise and uses correct third-person voice, clearly conveying the domain and the three governing properties of safe refactoring. Its main weakness is the absence of an explicit 'Use when...' trigger clause and limited trigger-term coverage, which cap both completeness and trigger quality at the midpoint.

Suggestions

Add an explicit trigger clause, e.g. 'Use when refactoring existing code, restructuring layers, or modifying implementations without changing behavior.'

Broaden trigger-term coverage with natural synonyms users might say, such as 'restructuring', 'cleanup', 'safe changes', or 'behavior-preserving edits'.

Convert one abstract quality into a concrete action framing (e.g. 'Preserves observable outputs and signatures during refactoring') to lift specificity above the attributes-only level.

DimensionReasoningScore

Specificity

Names the domain ('refactoring') and three specific qualities ('deterministic, behavior-preserving, and non-breaking'), but these are abstract constraints rather than concrete actions like 'extract' or 'fill', so it sits at the domain-plus-attributes level rather than a comprehensive action list.

3 / 5

Completeness

It clearly states what the skill does ('Ensures all refactoring is deterministic, behavior-preserving, and non-breaking') but has no 'Use when...' clause or equivalent trigger guidance, which per the judging guidelines caps completeness at 3.

3 / 5

Trigger Term Quality

'refactoring' is a natural keyword users would say, and the quality terms are real, but there is only one core trigger term with no common synonyms or variations, matching the 'some relevant keywords but missing variations' anchor.

3 / 5

Distinctiveness Conflict Risk

'Safe refactoring rules' is a fairly distinct niche narrowed by the three quality qualifiers, with only minor overlap risk against closely related coding or architecture skills, fitting the 'mostly distinct' anchor.

4 / 5

Total

13

/

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
Bottelet/DaybydayCRM
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.