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 validating and coercing request parameters in Hanami 2.x Actions.
Core principle: Params are validated at the boundary. Invalid input never reaches business logic.
params block inside the Action class with required/optional fields and typesrequest.params.errors — inspect or return errors if you need custom responsesdef handle(request, response)
# Step 3: check errors (optional — Hanami already halted if invalid)
if request.params.errors.any?
response.status = 422
response.body = { errors: request.params.errors.to_h }.to_json
return
end
# Step 4: proceed with validated, coerced params
result = user_repo.create(request.params[:user])
response.status = 201
response.body = result.to_json
end| Scenario | Syntax |
|---|---|
| Required param | required(:email).value(:string) |
| Optional param | optional(:bio).value(:string) |
| Integer coercion | required(:age).value(:integer) |
| Boolean coercion | required(:active).value(:bool) |
| Date coercion | required(:birth_date).value(:date) |
| Format constraint | required(:email).value(:string, format?: /\A.+@.+\z/) |
| Size constraints | required(:name).value(:string, min_size?: 1, max_size?: 100) |
| Numeric range | required(:age).value(:integer, gt?: 0, lteq?: 120) |
| Enum validation | required(:role).value(:string, included_in?: %w[admin member guest]) |
| Nested params | required(:user).hash { required(:name).value(:string) } |
| Array param | required(:tags).array(:string) |
| Custom rule | rule(:email) { key.failure("is invalid") unless value.include?("@") } |
| Access param | request.params[:key] (returns coerced value) |
| Read errors | request.params.errors.to_h |
Define params inside the Action class:
# app/actions/users/create.rb
# frozen_string_literal: true
module MyApp
module Actions
module Users
class Create < MyApp::Action
include Deps["repos.user_repo"]
params do
required(:user).hash do
required(:email).value(:string, format?: /\A.+@.+\z/)
required(:first_name).value(:string, min_size?: 1)
required(:last_name).value(:string, min_size?: 1)
optional(:bio).value(:string)
optional(:role).value(:string, included_in?: %w[admin member guest])
end
end
def handle(request, response)
result = user_repo.create(request.params[:user])
response.status = 201
response.body = result.to_json
end
end
end
end
endCustom rules for cross-field validation:
params do
required(:password).value(:string, min_size?: 8)
required(:password_confirmation).value(:string)
rule(:password_confirmation) do
key.failure("must match password") unless value == values[:password]
end
end| Mistake | Reality |
|---|---|
| Validating in the Repository instead of the Action | Params are validated at the HTTP boundary. Repositories receive already-validated data. |
Accessing request.params without a params block | Without a params block, request.params is an untrusted hash. Always define the schema. |
Putting business rules in the params block | Params validation checks shape and constraints. Business rules belong in interactors or service objects. |
| Duplicating params schemas across multiple Actions | Extract shared params to a module or base class if multiple Actions share the same input shape. |
| Complex nested params without hash/array declarations | Always use .hash {} and .array() for nested structures; untyped nesting is unsupported. |
| Related Skill | When to chain |
|---|---|
| create-action | Params are defined inside Actions. Master Action structure first. |
| handle-errors | Invalid params trigger automatic halts. Handle errors gracefully. |
| build-json-api | JSON request bodies are parsed and validated through the Params DSL. |
| handle-result-pattern | Validated params are passed to interactors that return Success/Failure. |
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