Curated library of 28 public AI agent skills for Ruby on Rails development. Organized by category: testing, code-quality, engines, infrastructure, api, and context. Covers code review, architecture, security, testing (RSpec), engines, Hotwire, and TDD automation. Shared Ruby skills (YARD docs, DDD, service objects) have moved to ruby-core-skills. Repository agents remain documented in GitHub but are intentionally excluded from the Tessl tile.
93
95%
Does it follow best practices?
Impact
93%
1.78xAverage score across 28 eval scenarios
Passed
No known issues
| Gem | Pattern | Best For |
|---|---|---|
| Pundit | Explicit policy classes | Complex per-resource rules |
| CanCanCan | Centralized Ability class | Simple role-based permissions |
ALWAYS test authorization with multiple roles (admin, user, guest)
NEVER rely on presence checks alone — check specific permissions
ALWAYS use policy objects, never inline authorization logic in controllerspundit or cancancan to Gemfile and run bundle installrails g pundit:install or rails g cancan:ability)authorize @record (Pundit) or authorize! :action, @record (CanCanCan) in each actionPundit::NotAuthorizedError or CanCan::AccessDenied as expectedpolicy_scope(Model) or accessible_by(current_ability) for index actionsclass PostPolicy < ApplicationPolicy
def update?
user.admin? || record.user_id == user.id
end
endclass Ability
include CanCan::Ability
def initialize(user)
can :update, Post, user_id: user.id
can :manage, :all if user.admin?
end
end| Error | Likely Cause | Fix |
|---|---|---|
Pundit::NotDefinedError | No policy class found for the record | Create app/policies/model_policy.rb inheriting from ApplicationPolicy |
Pundit::AuthorizationNotPerformedError | authorize not called in a controller action | Add authorize @record in the action, or after_action :verify_authorized to catch misses |
CanCan::AccessDenied unexpectedly raised | Ability rules not matching the current user/role | Inspect current_ability.can?(:action, @record) in the console to debug rule evaluation |
Cover every role (admin, owner, guest) in both policy specs and request specs.
RSpec.describe PostPolicy do
subject { described_class.new(user, post) }
let(:post) { create(:post, user: owner) }
let(:owner) { create(:user) }
context 'as admin' do
let(:user) { create(:user, :admin) }
it { is_expected.to permit_action(:update) }
end
context 'as owner' do
let(:user) { owner }
it { is_expected.to permit_action(:update) }
end
context 'as guest' do
let(:user) { create(:user) }
it { is_expected.not_to permit_action(:update) }
end
end| Skill | When to chain |
|---|---|
| write-tests | When implementing authorization tests. |
agents
docs
evals
scenario-1
scenario-2
scenario-3
scenario-4
scenario-5
scenario-6
scenario-7
scenario-8
scenario-9
scenario-10
scenario-11
scenario-12
scenario-13
scenario-14
scenario-15
scenario-16
scenario-17
scenario-18
scenario-19
scenario-20
scenario-21
scenario-22
scenario-23
scenario-24
scenario-25
scenario-26
scenario-27
scenario-28
skills
api
generate-api-collection
implement-graphql
code-quality
apply-code-conventions
apply-stack-conventions
assets
snippets
code-review
refactor-code
review-architecture
security-check
context
load-context
setup-environment
engines
create-engine
create-engine-installer
document-engine
extract-engine
release-engine
review-engine
test-engine
upgrade-engine
infrastructure
implement-background-job
implement-hotwire
optimize-performance
review-migration
seed-database
version-api
testing
plan-tests
test-service
write-tests