sandi-metz-rules
This skill should be used when users request code review, refactoring, or code quality improvements for Ruby codebases. Apply Sandi Metz's four rules for writing maintainable object-oriented code - classes under 100 lines, methods under 5 lines, no more than 4 parameters, and controllers instantiate only one object. Use when users mention "Sandi Metz", "code quality", "refactoring", or when reviewing Ruby code for maintainability.
79
67%
Does it follow best practices?
Impact
100%
1.17xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./tests/ext_conformance/artifacts/agents-mikeastock/skills/sandi-metz-rules/SKILL.mdQuality
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 articulates what the skill does (applies Sandi Metz's four specific rules to Ruby code), when to use it (with explicit trigger terms), and occupies a distinct niche. The description is concise yet comprehensive, listing concrete rules and natural trigger terms that make it easy for Claude to select appropriately.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions and rules: classes under 100 lines, methods under 5 lines, no more than 4 parameters, controllers instantiate only one object. Also names code review, refactoring, and code quality improvements as concrete actions. | 3 / 3 |
Completeness | Clearly answers both 'what' (apply Sandi Metz's four rules for maintainable OO code with specific rule details) and 'when' (explicit 'Use when' clause with trigger terms like 'Sandi Metz', 'code quality', 'refactoring', reviewing Ruby code). | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms users would actually say: 'Sandi Metz', 'code quality', 'refactoring', 'Ruby', 'code review', 'maintainability'. These cover common variations of how users would phrase requests in this domain. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive due to the specific focus on Sandi Metz's rules, Ruby codebases, and the enumerated four rules. This is unlikely to conflict with generic code review or refactoring skills because of the named methodology and language specificity. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
35%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is well-structured and covers the topic comprehensively, but suffers from significant verbosity - it explains many concepts Claude already knows (design patterns, SRP, guard clauses) and includes content that should live in the referenced rules.md file. The actionability is mixed: counting rules and RuboCop config are concrete, but refactoring guidance remains at the abstract pattern-name level without the before/after examples it promises. The workflow would benefit from explicit validation checkpoints and feedback loops.
Suggestions
Cut the content by ~50%: remove explanations of well-known patterns/principles (SRP, Strategy, Decorator, etc.) and move detailed refactoring strategies to references/rules.md, keeping only a brief summary in SKILL.md
Add concrete before/after Ruby code examples for at least one refactoring per rule (e.g., extracting a class from a 150-line class, breaking a 10-line method into smaller ones)
Add explicit validation feedback loops to the workflow: after refactoring, re-run the counting analysis to verify no new violations were introduced, then verify tests pass
Remove the 'When to Use This Skill' section entirely - this belongs in frontmatter metadata, not in the skill body
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Significant verbosity throughout. The 'When to Use This Skill' section repeats what should be in frontmatter. Extensive explanation of concepts Claude already knows (SRP, design patterns, what guard clauses are). The 'Consider Context' section lists obvious exceptions. The 'Resources' section at the end redundantly describes what's in the reference file. | 1 / 3 |
Actionability | The code counting rules with Ruby examples are concrete and useful, and the RuboCop configuration is copy-paste ready. However, the refactoring suggestions are largely abstract lists of patterns (e.g., 'Apply patterns: Strategy, Decorator, Command, Facade') without executable before/after code examples despite explicitly promising them in step 4. | 2 / 3 |
Workflow Clarity | Multiple workflow patterns are listed with numbered steps, but validation checkpoints are weak. Step 4 in Pattern 3 says 'Verify that tests still pass' but doesn't specify how. The review workflow lacks explicit feedback loops - there's no 'if refactoring introduces new violations, re-check' step. For a destructive operation like refactoring, this is insufficient. | 2 / 3 |
Progressive Disclosure | References to 'references/rules.md' are present and clearly signaled, which is good. However, the main SKILL.md contains too much inline content that could be in the reference file (detailed refactoring strategies, all the pattern lists, automation configuration). The overview should be leaner with more content pushed to the reference document. | 2 / 3 |
Total | 7 / 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
- Dicklesworthstone/pi_agent_rust
- Commit
6e3d68c
- 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.