igmarin/rails-agent-skills
Curated library of AI agent skills for Ruby on Rails development. Covers code review, architecture, security, testing (RSpec), engines, service objects, DDD patterns, and workflow automation.
73
91%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
86%
Use when creating or modifying REST API endpoints (Rails controllers, engine routes, API actions). Requires generating or updating an API Collection file (e.g., Postman Collection v2.1) so the new or changed endpoints can be tested. Trigger words: endpoint, API route, controller action, API collection, request collection.
94%
Generates a clear, actionable Product Requirements Document (PRD) in Markdown from a feature description. Use when a user asks to plan a feature, define requirements, or create a PRD. Covers goals, user stories, requirements, and non-goals for Rails-oriented workflows.
90%
Use when reviewing a Ruby on Rails app for Domain-Driven Design boundaries, bounded contexts, language leakage, cross-context orchestration, or unclear ownership. Covers context mapping, leakage detection, and smallest credible boundary improvements.
100%
Use when modeling Domain-Driven Design concepts in a Ruby on Rails codebase. Covers Rails-first mapping of entities, aggregates, value objects, domain services, application services, repositories, and domain events without over-engineering or fighting Rails conventions.
94%
Use when a Ruby on Rails feature, bug, or architecture discussion has fuzzy business terminology and you need shared vocabulary. Identifies canonical terms, resolves naming conflicts, maps synonyms to one concept, and generates a glossary for Rails-first workflows. Trigger words: DDD, shared vocabulary, define terms, bounded context naming, what should we call this, terminology alignment, DDD glossary, naming inconsistency.
78%
Generates phased plans or step-by-step task lists in Markdown from a PRD or feature description. Tasks include checkboxes, relevant file paths, test commands, YARD documentation, and code-review gates for Rails-oriented workflows.
70%
This skill is the starting point for all Rails tasks. It identifies the correct, more specialized skill to use for a given task, like code reviews, TDD, or documentation, and enforces the 'Tests Gate Implementation' mandate.
93%
Use when reviewing Rails application structure, identifying fat models or controllers, auditing callbacks, concerns, service extraction, domain boundaries, or general Rails architecture decisions. Covers controller orchestration, model responsibilities, and abstraction quality.
82%
Use when adding or reviewing background jobs in Rails. Covers Active Job, Solid Queue (Rails 8+), Sidekiq, recurring jobs, idempotency, retry/discard strategies, and queue selection.
78%
Use when investigating a bug in a Ruby on Rails codebase and you need to turn the report into a reproducible failing spec and fix plan. Covers reproduction, scope narrowing, boundary selection, and TDD-first handoff.
76%
A daily checklist for writing clean Rails code, covering design principles (DRY, YAGNI, PORO, CoC, KISS), per-path rules (models, services, workers, controllers), structured logging, and comment discipline. Defers style and formatting to the project's configured linter(s).
79%
Reviews Rails pull requests, focusing on controller/model conventions, migration safety, query performance, and Rails Way compliance. Covers routing, ActiveRecord, security, caching, and background jobs. Use when reviewing existing Rails code for quality.
64%
Use when maintaining compatibility for Rails engines across Rails and Ruby versions. Trigger words: Zeitwerk, autoloading, Rails upgrade, dependency bounds, gemspec, feature detection, CI matrix, reload safety, deprecated APIs, cross-version support.
75%
Use when writing or maintaining documentation for Rails engines. Trigger words: engine README, installation guide, configuration docs, mount instructions, migration notes, extension points, host integration examples, setup documentation.
77%
Use when extracting existing Rails app code into a reusable engine. Trigger words: extract to engine, move feature to engine, host coupling, adapters, extraction slices, preserve behavior, incremental extraction, bounded feature.
97%
Use when creating install generators, copied migrations, or initializer installers for Rails engines. Covers idempotent setup tasks, host-app onboarding, and route mount setup. Trigger words: install generator, mountable engine setup, gem installation, engine onboarding, rails plugin installer, copy migrations, initializer generator, route mount setup, engine configuration generator.
79%
Use when preparing a release, updating gemspec, writing changelog, handling deprecations, setting semantic version, planning upgrade notes, migration guide, or shipping a Rails engine as a gem. Trigger words: version bump, changelog, deprecation, gemspec, upgrade, migration guide, release.
90%
Use when reviewing a Rails engine, mountable engine, or Railtie. Covers namespace boundaries, host-app integration, safe initialization, migrations, generators, and dummy app test coverage. Prioritizes architectural risks.
80%
Use when creating or improving RSpec test coverage for Rails engines. Covers dummy app setup, request, routing, generator, and configuration specs for proving engine behavior within a host application.
90%
Use when building or reviewing GraphQL APIs in Rails with the graphql-ruby gem. Covers schema design, N+1 prevention with dataloaders, field-level auth, query limits, error handling, and testing resolvers/mutations with RSpec.
97%
Use when planning or reviewing production database migrations, adding columns, indexes, constraints, backfills, renames, table rewrites, or concurrent operations. Covers phased rollouts, lock behavior, rollback strategy, strong_migrations compliance, and deployment ordering for schema changes.
100%
Use when you have received code review feedback on Rails code and need to decide what to implement, how to respond, and in what order. Covers evaluating reviewer suggestions, pushing back with technical reasoning, avoiding performative agreement, implementing feedback safely one item at a time, and triggering a re-review when needed.
84%
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.
100%
Use when writing new Rails code for a project using PostgreSQL, Hotwire, and Tailwind CSS. Covers MVC structure, query patterns, Turbo Frames/Streams, Stimulus controllers, and Tailwind components. For design principles, use rails-code-conventions.
88%
Use when choosing the best first failing spec or vertical slice for a Ruby on Rails change. Covers request vs model vs service vs job vs engine spec selection, system spec escalation, smallest safe slice planning, and Rails-first TDD sequencing.
97%
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.
88%
Use when writing, reviewing, or cleaning up RSpec tests for Ruby and Rails codebases. Covers spec type selection, factory design, flaky test fixes, shared examples, deterministic assertions, test-driven development discipline, and choosing the best first failing spec for Rails changes. Also applies when choosing between model, request, system, and job specs.
90%
Use when writing RSpec tests for service objects, API clients, orchestrators, or business logic in spec/services/. Covers instance_double, FactoryBot hash factories, shared_examples, subject/let blocks, context/describe structure, aggregate_failures, change matchers, travel_to, and error scenario testing.
85%
Use when integrating with external APIs in Ruby, creating HTTP clients, or building data pipelines. Covers the layered Auth, Client, Fetcher, Builder, and Domain Entity pattern with token caching, retry logic, and FactoryBot hash factories for test data.
90%
Use when creating or refactoring Ruby service classes in Rails. Covers the .call pattern, module namespacing, YARD documentation, standardized responses, orchestrator delegation, transaction wrapping, and error handling conventions.
84%
Use when building variant-based calculators with a single entry point that picks the right implementation (Strategy + Factory), or when adding a no-op fallback (Null Object). Covers SERVICE_MAP routing and RSpec testing.
85%
Drafts, classifies, and optionally creates tickets from an initiative plan. Use when the user provides a plan and wants ticket drafts, wants help shaping a plan into tickets, wants sprint-placement guidance, or wants tickets created in an issue tracker after the plan is approved.
90%
Use when writing or reviewing inline documentation for Ruby code. Covers YARD tags for classes and public methods (param, option, return, raise, example tags). Trigger words: YARD, inline docs, method documentation, API docs, public interface, rdoc.
Quality
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.
Reviewed
Table of Contents