Curated library of atomic AI agent skills for Hanami, dry-rb, and ROM Ruby development. Covers actions, slices, repositories, relations, changesets, providers, DI, operations, TDD, CLI, views, routing, and validation. Shared Ruby process skills have moved to ruby-core-skills. Uses Markdown + Front-matter architecture.
92
94%
Does it follow best practices?
Impact
92%
1.33xAverage score across 35 eval scenarios
Passed
No known issues
Use this skill when reviewing Hanami 2.x code for quality and convention adherence.
Core principle: Code review catches architectural violations, not just bugs. Focus on structure, boundaries, and testability.
| Concern | Rule | Priority |
|---|---|---|
| Action responsibility | One Action = one endpoint. No business logic. ≤ ~10 lines of logic. | Blocker if logic leaks |
| Dependency injection | include Deps[] only. No Hanami.app['key'] direct access. | Blocker |
| Query location | All DB queries in Repositories/Relations. No SQL in Actions or Views. | Blocker |
| Repository return types | Return Entities (auto_struct true, struct_namespace). No raw hashes. | High |
| View simplicity | expose blocks receive pre-fetched data only. No DB calls or business logic. | Blocker if DB in View |
| Error handling | Log and return generic messages. No e.message/e.backtrace in responses. | Blocker |
| Test coverage | Request specs per endpoint. Test 400, 404, 422, 500 paths. Behavior, not implementation. | High |
| Settings usage | No ENV access. Use Settings for configuration. | Suggestion |
Follow this sequence and report violations in priority order:
include Deps[...]? Flag any Hanami.app['key'] direct access.auto_struct true / struct_namespace configured?expose blocks receive pre-fetched data only? Flag any DB calls or business logic.e.message or e.backtrace in responses.For each violation found, report: location, rule broken, concrete fix (with code where helpful), and priority (blocker if it exposes internals or bypasses DI; suggestion otherwise).
1. Actions — single-responsibility, delegate logic:
# GOOD
class Index < MyApp::Action
include Deps["repos.user_repo"]
def handle(request, response)
response.render(view, users: user_repo.all)
end
end
# BAD — business logic and direct ROM access in Action
users = Hanami.app["db.rom"].gateways[:default].dataset(:users).where(status: "active").to_a
active_users = users.select { |u| u.status == "active" }2. Dependencies — always via Deps, never direct container:
# GOOD
include Deps["repos.user_repo"]
# BAD
repo = Hanami.app["repos.user_repo"]3. Repositories — return Entities, not raw hashes:
# GOOD
class UserRepo < Hanami::DB::Repo[:users]
struct_namespace MyApp::Entities
auto_struct true
end
# BAD
def find(id) = users.where(id: id).one.to_h4. Views — no DB queries or business logic in expose:
# GOOD
expose :user # receives pre-fetched entity from Action
# BAD
expose :user do |request|
Hanami.app["repos.user_repo"].by_id(request.params[:id]).one
end5. Error handling — log details, return generic messages:
# GOOD
rescue StandardError => e
Hanami.app[:logger].error(e.message)
halt 500, { error: "Internal server error" }.to_json
end
# BAD — leaks internals
halt 500, { error: e.message, backtrace: e.backtrace }.to_json6. Tests — cover behavior and all error paths:
# GOOD
it "returns 404 for unknown user" do
get "/users/9999"
expect(last_response.status).to eq(404)
end
# BAD — tests implementation, not behavior
expect(user_repo).to receive(:active)| Related Skill | When to chain |
|---|---|
| create-action | Review Action structure and responsibility. |
| inject-dependencies | Verify proper DI usage. |
| create-repository | Verify query encapsulation in Repositories. |
| create-view | Verify View simplicity and no DB access. |
| write-request-spec | Verify test coverage for all endpoints. |
| review-security | Cross-reference security concerns during code review. |
| review-process (from ruby-core-skills) | Severity levels, structured findings format, re-review criteria. |
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
scenario-29
scenario-30
scenario-31
scenario-32
scenario-33
scenario-34
scenario-35
skills
actions
build-json-api
create-action
handle-errors
validate-params
context
load-context
db
create-changeset
create-repository
define-relation
write-migration
dry-monads
handle-result-pattern
dry-rb
create-operation
create-validation-contract
providers
configure-providers
implement-di
review-security
routing
define-routes
slices
configure-slice
create-slice
extract-slice
review-slice-boundaries
test-slice