rails-security-review
Use when reviewing Rails code for security risks, assessing authentication or authorization, auditing parameter handling, redirects, file uploads, secrets management, or checking for XSS, CSRF, SSRF, SQL injection, and other common vulnerabilities.
85
80%
Does it follow best practices?
Impact
91%
1.49xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./rails-security-review/SKILL.mdQuality
Discovery
82%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 description excels at trigger term coverage and specificity, listing numerous concrete security concerns and vulnerability types that would naturally match user requests. Its main weakness is the structural imbalance: it's entirely a 'Use when...' clause without a preceding declarative statement of what the skill does, which makes the 'what' only implicitly conveyed through the trigger conditions.
Suggestions
Add a declarative 'what' statement before the 'Use when' clause, e.g., 'Performs security audits and vulnerability assessments on Ruby on Rails application code.' followed by the existing 'Use when...' content.
Consider adding the term 'Ruby on Rails' in addition to 'Rails' to capture users who use the full framework name.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions and vulnerability types: reviewing Rails code for security risks, assessing authentication/authorization, auditing parameter handling, redirects, file uploads, secrets management, and checking for XSS, CSRF, SSRF, SQL injection. | 3 / 3 |
Completeness | The description is structured as a 'Use when...' clause, which clearly answers 'when should Claude use it', but it lacks an explicit 'what does this do' statement. There's no declarative description of the skill's capabilities (e.g., 'Performs security audits on Rails applications'). The 'what' is only implied through the 'when' triggers. | 2 / 3 |
Trigger Term Quality | Excellent coverage of natural terms users would say: 'security risks', 'authentication', 'authorization', 'parameter handling', 'redirects', 'file uploads', 'secrets management', 'XSS', 'CSRF', 'SSRF', 'SQL injection', 'Rails code', 'vulnerabilities'. These are all terms a developer would naturally use when requesting a security review. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with a clear niche: Rails-specific security auditing. The combination of 'Rails' with specific security concerns (XSS, CSRF, SSRF, SQL injection, authentication, authorization) creates a very distinct trigger profile unlikely to conflict with general code review or non-security Rails skills. | 3 / 3 |
Total | 11 / 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 well-structured, concise security review skill that provides clear guidance on what to look for, how to prioritize findings, and how to report them. Its main weakness is the lack of 'good' code examples showing correct patterns alongside the 'bad' examples, which would make the mitigation guidance more actionable. The organization is logical with effective use of tables, though the single-file approach puts a lot of content inline.
Suggestions
Add 'good' code examples alongside each 'bad' example (e.g., show a safe redirect using `redirect_to root_path` or an allowlist check, show proper `permit(:name, :email)` usage)
Consider extracting the Common Mistakes and Red Flags sections into a separate reference file to keep SKILL.md as a leaner overview
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Every section earns its place. No unnecessary explanations of what Rails is or how security works in general. Tables are used effectively to compress information. The skill assumes Claude knows Rails and focuses on what to check and how to report it. | 3 / 3 |
Actionability | The skill provides concrete 'bad' code examples and clear mitigation guidance, but lacks 'good' code examples showing the correct pattern (e.g., a safe redirect, proper parameterized query, correct permit usage). The review checklist and red flags are specific but remain at the checklist level rather than providing executable remediation code. | 2 / 3 |
Workflow Clarity | The review order provides a clear 5-step sequence for conducting the review. The output style section specifies exactly how to format findings (severity, attack path, affected file, mitigation). For a review/audit skill, this is an appropriate workflow with clear structure — validation here means identifying and reporting issues, which is well-defined. | 3 / 3 |
Progressive Disclosure | The integration table at the bottom provides good cross-references to related skills. However, all content is inline in a single file — the common mistakes table, red flags list, and detailed examples could potentially be split out for a cleaner overview. For a skill of this length (~100 lines of substantive content), it's borderline acceptable but slightly heavy. | 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.