refactor-safely
Use when the goal is to change code structure without changing behavior — this includes extracting a service object from a fat controller or model, splitting a large class, renaming abstractions, reducing duplication, or reorganizing modules. Covers characterization tests (write tests that document current behavior before touching the code), safe extraction in small steps, and verification after every step. Do NOT use for bug fixes or new features — those follow the TDD gate in rspec-best-practices. Do NOT mix structural changes with behavior changes in the same step.
90
88%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is an excellent skill description that clearly defines its scope (code refactoring without behavior changes), lists specific concrete actions, includes natural trigger terms developers would use, and explicitly delineates boundaries with other skills. The inclusion of DO NOT clauses referencing a related skill (rspec-best-practices) is particularly effective for disambiguation. The description uses appropriate third-person voice throughout.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: extracting a service object from a fat controller/model, splitting a large class, renaming abstractions, reducing duplication, reorganizing modules, writing characterization tests, safe extraction in small steps, and verification after every step. | 3 / 3 |
Completeness | Clearly answers both 'what' (refactoring operations like extracting service objects, splitting classes, characterization tests, safe extraction) and 'when' (explicit 'Use when the goal is to change code structure without changing behavior' plus clear exclusions for bug fixes and new features). | 3 / 3 |
Trigger Term Quality | Includes many natural keywords users would say: 'refactor', 'extract service object', 'fat controller', 'splitting a large class', 'renaming', 'reducing duplication', 'reorganizing modules', 'characterization tests'. These are terms developers naturally use when requesting refactoring help. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with clear boundaries — explicitly states it's for structural changes only, not bug fixes or new features, and references the TDD gate in rspec-best-practices as the alternative. The DO NOT clauses create sharp boundaries that minimize conflict with other skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a strong skill with excellent workflow clarity and actionability. The verification protocol with its hard gate and feedback loops is particularly well done, and the concrete extraction example grounds the abstract principles. The main weakness is moderate redundancy — the core message of 'run tests after every step' appears in at least 5 different sections, and the refactoring order duplicates the quick reference table.
Suggestions
Consolidate the repeated 'verify after every step' messaging — state it once emphatically in the HARD-GATE and Verification Protocol sections, then reference it rather than restating it in Common Mistakes, Red Flags, and Output Style.
Remove the 'Refactoring Order' section since it duplicates the Quick Reference table almost exactly, or merge them into one.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is mostly efficient but has some redundancy — the refactoring order (section) largely duplicates the quick reference table, and the verification protocol repeats the 'run tests after every step' message multiple times across sections (HARD-GATE, Verification Protocol, Common Mistakes, Red Flags). Some tightening would help. | 2 / 3 |
Actionability | Provides concrete, specific guidance: a clear step-by-step extraction example (OrdersController → Orders::CreateOrder), specific verification commands (run full test suite, check exit code, count failures), explicit forbidden claims, and actionable 'good first moves'. While not code-heavy, this is an instruction-oriented skill where the guidance is highly specific and actionable. | 3 / 3 |
Workflow Clarity | The workflow is clearly sequenced with explicit validation checkpoints after every step, a hard gate requiring characterization tests before starting, and a clear feedback loop (fail → stop → undo → investigate). The verification protocol is thorough with explicit error recovery steps. | 3 / 3 |
Progressive Disclosure | The content is well-structured with clear sections and a quick reference table, and the integration table at the end provides good cross-references. However, the content is fairly long and some sections (Common Mistakes, Red Flags) could potentially be split into a reference file. The skill is self-contained but borders on having too much inline content. | 2 / 3 |
Total | 10 / 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.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- igmarin/rails-agent-skills
- Commit
ae8ea63
- 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.