CtrlK
BlogDocsLog inGet started
Tessl Logo

safe-refactoring-rules

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

55

Quality

61%

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

72%

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 lean, well-organized set of refactoring safety rules that respects the context window and clearly scopes responsibilities versus other skills. Its main gaps are the absence of positive executable guidance and a validation/verification loop for the refactoring operation itself.

Suggestions

Add a brief positive 'how to' example or checklist for a safe refactor (e.g., locate call sites, update signatures, re-run tests) to complement the prohibitive rules and raise actionability.

Insert an explicit validation checkpoint after refactoring, such as 'run the test suite and confirm no behavior change before completing', to add the missing verify-fix-retry loop.

Clarify the idempotency rule with a concrete check (e.g., 're-apply the change and assert an empty diff') so the workflow is executable rather than stated only as a property.

DimensionReasoningScore

Conciseness

The body is almost entirely short directive bullets that assume Claude already knows concepts like dependency injection, traits, and DTOs, with no concept explanation or padding; nearly every token earns its place.

3 / 3

Actionability

Rules are concrete prohibitions with some specifics (e.g., banning service locators 'app()', 'resolve()'), but guidance is overwhelmingly negative with no positive executable examples showing how to safely extend or restructure code, leaving it incomplete.

2 / 3

Workflow Clarity

The uncertainty-handling sequence and enforcement-priority ordering provide clear sequences, but the core refactoring operation has no explicit validation or verify-fix-retry checkpoint; per the rubric, missing validation for a destructive operation caps this at 2.

2 / 3

Progressive Disclosure

The skill is organized into a clear Purpose overview plus nine well-labeled numbered sections, with cross-skill references (section 8) explicitly scoped and one-level deep; the cohesive single-file structure is appropriately organized for a rules skill.

3 / 3

Total

10

/

12

Passed

Description

50%

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 clearly scopes the skill to safe refactoring and lists meaningful constraints, but it lacks explicit 'when to use' triggers and natural-language variations that would help it surface at the right moment. It reads as a constraint summary rather than a trigger-rich capability statement.

Suggestions

Add an explicit 'Use when...' clause naming natural triggers such as 'refactoring code', 'restructuring a codebase', or 'renaming or moving methods' so the skill surfaces reliably.

Replace abstract qualifiers with at least one concrete action phrase (e.g., 'renames, moves, and restructures code without changing behavior') to lift specificity.

Include common user phrasings like 'safe refactor' or 'refactor without breaking' to improve trigger term coverage and distinctiveness.

DimensionReasoningScore

Specificity

Names the domain ('refactoring') and three specific qualities ('deterministic, behavior-preserving, and non-breaking'), but these are constraints rather than concrete actions, so it does not reach the 'multiple specific concrete actions' anchor.

2 / 3

Completeness

It states what the skill does (enforce deterministic, behavior-preserving, non-breaking refactoring) but provides no 'Use when...' or equivalent explicit trigger guidance, which per the judging guidelines caps completeness at 2.

2 / 3

Trigger Term Quality

'refactoring' is a natural term a user would say, but the description misses common variations like 'safe refactor', 'refactor code', or 'rename/restructure', and the qualifiers are technical rather than natural phrasings.

2 / 3

Distinctiveness Conflict Risk

Scoped to refactoring safety it is more specific than generic code/doc skills, but without distinct triggers it could still overlap with architecture or general coding skills.

2 / 3

Total

8

/

12

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.

Validation16 / 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.