igmarin

@igmarin source repo

160 skills
0 followers
11 hours ago last updated

▌
Elixir Skill Router · igmarin bundle
Entry-point orchestrator that triages and decomposes complex Elixir/Phoenix requests into ordered sub-tasks, then delegates to the correct specialised skill — never implements directly. Enforces TDD discipline across all code-producing work. Priority order: TDD → Planning → Implementation → Quality → Review. First response line MUST be "Next skill: skills/<name>". Prefer playbooks for multi-step work (e.g. skills/tdd, skills/code-review-playbook). Falls back to `elixir-essentials` for language ambiguity or `phoenix-liveview-essentials` for web ambiguity. Use when scope is unclear, best approach uncertain, or request spans multiple concerns. Trigger words: where do I start, help me plan, break this down, best approach, not sure how, multi-step, complex task, complex Phoenix, what should I do first, orchestrate, triage, route to skill, skill routing, entry point, skill router.

0
installs
▌
Security Essentials · igmarin bundle
Provides security guidelines and patterns for Elixir/Phoenix applications. Use when writing auth, token handling, redirects, or user input processing, or when any security concern arises. Covers atom exhaustion, SQL injection, open redirects, XSS, sensitive data in logs, timing attacks, CSRF, and dependency auditing. Trigger words: security, atom exhaustion, SQL injection, XSS, open redirect, timing attack, CSRF, Sobelow.

0
installs
▌
Code Review Playbook · igmarin
Sequenced PR/diff review workflow with hard gates and optional HITL on Critical fixes: integrity of PR text → load atomic review rules → walk Review Order → severity findings → handoff task list → re-review after Critical changes. Trigger: code review, PR review, review my diff, review before merge, self-review, code audit.

0
installs
▌
Mix Tasks Generators · igmarin
MANDATORY when creating custom Mix tasks or using Phoenix generators. Invoke before defining custom Mix task modules with argument parsing and subcommands, scaffolding resources with phx.gen.live or phx.gen.context, generating authentication systems with phx.gen.auth, configuring dependencies and aliases in mix.exs, or writing tests for custom tasks. Covers Mix.Tasks module creation, generator patterns, and Mix project configuration. Trigger words: Mix task, custom task, phx.gen, generators, mix.exs, project configuration, phx.gen.live, phx.gen.auth, scaffold, seed data, ecto.setup, mix help, Mix.Project, OptionParser, @shortdoc, preferred_cli_env, alias, mix run, generator, phx.gen.html, phx.gen.context, phx.gen.json, phx.gen.channel.

0
installs
▌
Telemetry Essentials · igmarin bundle
MANDATORY for ALL telemetry, logging, and observability work. Invoke before writing telemetry handlers, Logger calls, or metrics code. Covers structured logging, :telemetry basics, Ecto events, Phoenix events, LiveDashboard, custom business metrics, and external tool integration. Trigger words: telemetry, logging, Logger, metrics, LiveDashboard, observability, structured logging.

0
installs
▌
Phoenix Liveview Auth · igmarin bundle
MANDATORY for ALL LiveView authentication work. Invoke before writing on_mount hooks, auth plugs for LiveViews, or session handling in LiveView modules. Covers on_mount patterns, current_scope, import conflict resolution, safe template access, and testing auth redirects. Trigger words: on_mount, LiveView auth, current_scope, session, live_session, redirect_if_authenticated.

0
installs
▌
Apply Ecto Conventions · igmarin
Use when writing or reviewing Ecto database code in Elixir applications. Enforces consistent patterns for Repo queries, changeset composition, preloading strategies, context boundaries, Ecto.Multi transactions, and query composition. Covers non-bang vs bang functions, N+1 prevention, pagination, and migration safety. Trigger words: ecto conventions, repo pattern, changeset, context module, preload, ecto query, database conventions, apply ecto patterns.

0
installs
▌
Property Based Testing · igmarin
Use when writing tests that need to cover many input combinations or complex edge cases. Generates custom StreamData generators, writes ExUnitProperties tests, configures shrinking strategies, and creates property-based test patterns for data transformations, algorithms, and state machines. Trigger words: property-based testing, StreamData, ExUnitProperties, generators, fuzzing, shrinking.

0
installs
▌
Broadway Data Pipelines · igmarin bundle
MANDATORY when building data processing pipelines or consuming message queues. Invoke before implementing GenStage or Broadway consumers. Covers Broadway setup, producers, processors, batchers, and error handling. Trigger words: Broadway, GenStage, data pipeline, message queue, consumer, producer, batcher, SQS, Kafka, RabbitMQ, broadway_sqs, broadway_kafka, handle_message, handle_batch, handle_failed, Broadway.start_link, Broadway.Message, push_message, dead letter queue, DLQ.

0
installs
▌
Ecto Changeset Patterns · igmarin
MANDATORY for ALL changeset work beyond basic CRUD. Invoke before writing multiple changesets, cast_assoc, or conditional validation. Covers separate changesets per operation, cast_assoc pitfalls, composition, conditional validation with opts, field transformations, and uniqueness validation. Trigger words: changeset, cast_assoc, validation, separate changesets, conditional validation, update_change.

0
installs
▌
Phoenix Pubsub Patterns · igmarin
MANDATORY for ALL PubSub and real-time broadcast work. Invoke before writing PubSub.subscribe, broadcast, or handle_info for real-time updates. Covers subscription patterns, broadcasting from contexts, topic naming, scoped broadcasting, immutable assign updates, and testing. Trigger words: PubSub, subscribe, broadcast, handle_info, real-time, topic, presence.

0
installs
▌
Ecto Nested Associations · igmarin
MANDATORY for ALL nested association and multi-table work. Invoke before writing cast_assoc, cast_embed, Ecto.Multi, or cascade operations. Covers nested creates, updates with on_replace, Ecto.Multi for unrelated tables, on_delete strategies, and FK indexes. Trigger words: cast_assoc, cast_embed, Ecto.Multi, nested, association, cascade, on_delete, on_replace, has_many, has_one, belongs_to, many_to_many, preload, nested_changeset, multi-table transaction, atomic create, atomic update.

0
installs
▌
Phoenix Auth Customization · igmarin
MANDATORY when extending phx.gen.auth with custom fields. Invoke before adding usernames, profiles, or custom registration fields. Covers migrations, schema updates, fixture updates, form changes, and confirmation patterns. Trigger words: phx.gen.auth, custom fields, registration, username, profile, auth customization.

0
installs
▌
Phoenix Channels Essentials · igmarin bundle
Handles all Phoenix Channels work. Use when building socket authentication, topic authorization, handle_in patterns, Presence tracking, or channel testing. Covers non-LiveView real-time features for mobile clients, SPAs, and external APIs. Trigger words: Channels, socket, channel, Presence, handle_in, topic, real-time, WebSocket.

0
installs
▌
Phoenix Liveview Essentials · igmarin bundle
MANDATORY for ALL LiveView work. Invoke before writing LiveView modules or .heex templates. Covers the two-phase rendering lifecycle, mount/handle_event/handle_info/handle_params callbacks, socket assigns, streams, components, form binding, error handling, and PubSub integration. Trigger words: LiveView, live_view, mount, handle_event, handle_info, render, HEEx, socket, assign.

0
installs
▌
Phoenix Authorization Patterns · igmarin
Handles all authorization and access control work in Phoenix and LiveView applications. Covers server-side authorization, owner-only patterns, scoped queries, policy modules, controller authorization, and authorization testing. Use when writing permission checks, policy modules, or role-based access controls, or when addressing authorization, access control, permission, policy, role, owner, scoped query, or IDOR concerns.

0
installs
▌
Apply Phoenix Liveview Conventions · igmarin
Use when writing new LiveView code in Phoenix applications. Enforces consistent patterns for mount/handle_event/handle_info/handle_params callbacks, HEEx component structure, form binding, socket assigns, and error handling. Covers the two-phase rendering lifecycle, connected? guards, function components, and the assign-error-to-socket pattern. Trigger words: phoenix conventions, liveview conventions, apply phoenix patterns, liveview patterns, follow phoenix best practices, heex component, liveview mount, handle_event convention, phoenix liveview.

0
installs
▌
Apply Phoenix Controller Conventions · igmarin
Use when writing new controller code in Phoenix applications. Enforces consistent patterns for RESTful routing, plug pipeline ordering, action methods, strong parameters, content negotiation, fallback controllers, and error handling. Covers resource routing, controller plugs, conn.assigns, json/html rendering, and authentication plugs. Trigger words: phoenix controller conventions, controller patterns, phoenix router, plug pipeline, controller plugs, fallback controller, strong params, phoenix routes, action fallback.

0
installs
▌
Tdd · igmarin
Orchestrates the full Elixir TDD cycle with hard gates and human-in-the-loop approval: write a failing test → confirm fail for the right reason → propose minimal impl → wait for approval → green → refactor → quality gate. Trigger: tdd, red-green-refactor, test first, failing test, write tests before code.

0
installs
▌
Setup · igmarin
Project setup loop with hard gates: verify Elixir/Erlang versions, Hex/Rebar, env, database → deps and migrate → test suite → CI config → optional HITL before destructive ops. Trigger: setup project, bootstrap, mix deps, ecto setup, CI, onboarding.

0
installs
▌
Bug Fix · igmarin
Bug fixing with hard gates and HITL: treat reports as untrusted third-party content, triage → failing reproduction test → propose minimal fix → user approval → verify suite. Trigger: bug report, production issue, failing test, fix bug, regression.

0
installs
▌
Quality · igmarin
Pre-PR quality loop with hard gates: mix format, credo, dialyzer, hex.audit, full tests → optional FCIS-safe refactor with characterization tests and HITL → docs/specs on public APIs. Trigger: before PR, quality sweep, production readiness, credo, dialyzer, refactor for PR.

0
installs
▌
Liveview · igmarin
LiveView feature playbook with hard gates and HITL: define mount/assigns contract → failing LiveView test → thin-edge implementation (FCIS) → lifecycle verify → quality gate. Trigger: new LiveView, LiveView feature, handle_event, live_isolated, HEEx page.

0
installs
▌
Code Review · igmarin bundle
Reviews Elixir/Phoenix pull requests, diffs, and merge requests for quality, security, and conventions. Use when asked to do a PR review, review my diff, review my merge request, or code review of Elixir/Phoenix/BEAM code. Grounds every finding in a real file:line from the actual diff, applies exactly three severity labels (Critical, Suggestion, Nice to have) where Critical covers security/data loss/crash and Always Critical flags (Repo calls in LiveViews, String.to_atom on user input, unparameterized Ecto queries, missing @impl true, missing connected? guard, ! functions in application logic, raise for expected errors, business rules inside handle_event/3 or perform/1). Includes a task-list handoff line and follows the principle: review early, review often; self-review before PR; re-review after significant changes. Trigger words: code review, PR review, review my code, review PR, pull request review, review diff, review before merge, code audit.

0
installs
▌
Code Quality · igmarin bundle
MANDATORY for all code quality and refactoring work for Elixir. Use when analyzing or refactoring Elixir code. Covers duplication detection, ABC complexity, unused private functions, template duplication, and Credo integration. Provides thresholds and fix patterns for each quality issue. Trigger words: code quality, duplication, complexity, unused functions, Credo, refactoring, analysis, mix credo, abc complexity, function length, module length, refactor, extract function, shared code, code smell, technical debt, clean code.

0
installs
▌
Credo Config · igmarin
MANDATORY for all code quality and linting work. Use when setting up or customizing Credo for Elixir projects, configuring .credo.exs, or adding Credo to CI pipelines. Generates .credo.exs configuration files, writes custom check modules, configures strictness levels, and integrates Credo into CI pipelines. Trigger words: Credo, .credo.exs, linting, code style, static analysis, custom checks, credo.config, mix credo, code quality, lint, static analysis, format check.

0
installs
▌
Create Slice · igmarin
Use when creating Hanami Slices — generate a slice with `hanami generate slice [name]`, register it in `config/app.rb` via `slice :name, at: "/path"`, define slice routes in `slices/[name]/config/routes.rb`, configure inter-slice dependencies with `import`/`export` (avoid circular deps: if A imports from B, B must not import from A), and keep slices self-contained for distinct bounded contexts like API, admin, or billing, the main web application. Covers slice directory generation, route configuration, cross-slice dependency management, and slice-level container access.

0
installs
▌
Load Context · igmarin bundle
Loads the Hanami application context before any code, spec, or review work — discovers slices, providers, settings, routes, ROM setup, test framework, DI conventions, and existing patterns, with a mandatory security gate to redact all passwords/credentials/tokens/API keys before note-taking, and a rule to never propose code without first running load-context. The non-negotiable first step for every Hanami task. Trigger words: load context, before I code, what does this app use, match existing style, load-context, show me the app, discover structure, context.

0
installs
▌
Create Repository · igmarin bundle
Use when creating ROM Repositories in Hanami 2.x, including CRUD operations, defining custom queries, configuring associations, setting up aggregate roots, entity mapping, transaction handling, and implementing the Repository as your domain persistence layer. Relevant for database access, rom-rb relations, sequel adapter setup, and wiring repositories into actions via dependency injection.

0
installs
▌
Register Provider · igmarin
Use when registering external dependencies in Hanami 2.x — integrating a gem, wiring up a service, or setting up dependency injection for databases, mailers, caches, and third-party APIs. Creates provider files at `config/providers/[name].rb` using `hanami generate provider [name]`, implements lifecycle hooks with `prepare` for requiring gems and `start` for instantiation and service registration, registers components with a descriptive key using `register("name.client", instance)`, always loads configuration through `target[:settings]` never raw `ENV`, rescues and logs errors in `start` to prevent boot crashes, and verifies registration via `Hanami.app["key"]` in console or a lightweight smoke test.

0
installs
▌
Extract Slice · igmarin bundle
Extract code from Hanami app module into a dedicated slice — DO NOT change behavior, every test must pass after the move, identify bounded context, use `create-slice`, `git mv` preserving history, update namespaces App::X→X plus `Deps[...]` and route defs, run full test suite before and after, load supporting files only when needed (progressive disclosure). Covers identifying extraction boundaries, moving files while preserving history, updating imports and dependencies, and verifying the extraction. Trigger words: extract slice, extract to slice, move to slice, create slice from existing, refactor to slice, modularize.

0
installs
▌
Create Action · igmarin
Use when creating, generating, or reviewing Hanami 2.x Action classes (route handlers, request handling, hanami controller equivalents). Generates Action classes with proper handle method signatures, configures dependency injection via Deps[], renders views with exposures, validates params, redirects, returns JSON responses, sets HTTP status codes, and implements halt-based error handling. Use when building a hanami action, wiring a new endpoint, handling params, or structuring request/response logic in a Hanami 2.x app.

0
installs
▌
Handle Errors · igmarin
Use when handling errors and halting requests in Hanami 2.x Actions — fail fast with `halt STATUS, {error:}.to_json` for early returns, rescue `StandardError` (never `Exception`) logging full details internally but returning generic messages to clients, let invalid params halt automatically with 422 before `#handle` runs without manual `params.valid?` checks, and match error response format to action format (no HTML errors in JSON actions). Demonstrates halt status codes (404, 422, 500), rescue patterns, and consistent error shapes. Use when implementing error handling patterns, exception handling, or returning JSON error responses in Hanami actions.

0
installs
▌
Hanami Setup · igmarin
Orchestrates Hanami project onboarding: loads application context, configures providers, implements dependency injection patterns, and verifies the setup. Use when setting up a new Hanami project, onboarding a developer, configuring services and DI, or wiring up dry-container, dry-system, IoC containers, or Hanami app configuration with providers and dependency injection.

0
installs
▌
Define Routes · igmarin
Use when defining routes in Hanami 2.x. Covers get, post, patch, delete, resources, resource, scope, and named route helpers in config/routes.rb.

0
installs
▌
Build JSON API · igmarin bundle
Use when building JSON API endpoints in Hanami 2.x Actions — set `response.format = :json`, use dedicated serializers to encode response bodies, write round-trip serialize→parse tests asserting fields match with `.iso8601` timestamps, include pagination metadata with `{data:, meta:}` shape, return consistent error shapes across endpoints, and rescue `JSON::ParserError` with 400 status. Covers setting content-type headers, serializing Ruby objects to JSON, parsing incoming JSON request bodies, content negotiation, and round-trip parse → serialize → parse verification. Use when you need to render JSON, build a JSON endpoint, create an API controller action, or handle JSON request/response cycles in Hanami 2.x.

0
installs
▌
Inject Dependencies · igmarin
Use when injecting dependencies in Hanami 2.x — always use `include Deps["dir.name"]` to inject (never call `Hanami.app["key"]` directly outside of providers), derive container keys from file paths via `app/{dir}/{name}.rb` → `"{dir}.{name}"`, exclude ROM-managed relations/structs/entities from auto-registration via `no_auto_register_paths`, access the dependency by its last key segment — for example `Deps["repos.user_repo"]` → use `user_repo`, and override dependencies in tests by passing stubs to `.new(keyword:)`. Covers container keys, auto-registration rules, no_auto_register_paths, and testing with stubs.

0
installs
▌
Implement Di · igmarin bundle
Inject dependencies through Hanami's `auto_inject` using `Deps["provider_key"]` — never call `Hanami.app["key"]` outside of providers, dependencies must be pre-registered by a provider using a descriptive dot-namespaced snake_case key, inject via constructor (no custom `initialize`), pass `instance_double` test stubs through `.new(keyword:)` in specs, validate resolution to catch `Dry::Container::Error` on unregistered keys, and access dependencies by their last key segment — for example `Deps["repos.user_repo"]` → call `user_repo`. Use when adding DI to actions, operations, or repositories. Trigger words: dependency injection, DI, auto_inject, Deps, inject, dry-system, constructor injection, test with DI.

0
installs
▌
Configure Slice · igmarin
Creates and configures Hanami 2.x Slices by registering providers, setting up container dependencies, customizing auto-registration paths, and managing slice-level settings. Use when configuring slice setup, modular app structure, Hanami component registration, dependency injection, provider registration, container imports/exports, or autoloading for a Hanami 2.x Slice.

0
installs
▌
Write Rom Spec · igmarin
Use when writing ROM specs in Hanami 2.x — configure transactional rollback via a shared `"db rollback"` RSpec context wrapping every spec with `transaction(rollback: :always, auto_savepoint: true)`, place relation specs under `spec/relations/` and repository specs under `spec/repos/`, test custom Relation query methods with fully defined test data via `relation.insert(...)`, verify Repository CRUD operations including `one!` raising `ROM::TupleCountMismatchError` for missing tuples, and run specs to confirm failure before implementing. Use when testing Relation query methods, Repository CRUD operations, or entity creation and lookup in a Hanami ROM-backed app.

0
installs
▌
Validate Params · igmarin
Use when validating request parameters in Hanami 2.x Actions, including defining required/optional params blocks, applying type coercion (integer, bool, date), validating nested and array params, adding constraints, writing custom cross-field rules, and handling validation errors with 422 responses. Covers params block DSL, dry-validation predicates, input validation, action params, parameter types, and coercion of request input at the HTTP boundary.

0
installs
▌
Generate Components · igmarin
Use when generating Hanami 2.x components via CLI. Covers hanami generate action, view, slice, migration with output paths and naming conventions.

0
installs
▌
Create Operation · igmarin bundle
Encapsulate a business workflow in a `Dry::Operation` with explicit steps returning `Success(value)` or `Failure(error)` — inject dependencies via `include Deps[...]`, place the class in `slices/[slice]/operations/`, compose operations by injecting them as dependencies (never call one operation from inside another's private methods), pass test doubles through the constructor to verify step ordering, and delegate from actions that map results to HTTP responses. Composes validation, persistence, and side effects into explicit steps using the step/Do notation. Use when the user asks to create a business operation, service object, or workflow using dry-operation, dry-transaction, or Hanami operations. Trigger words: operation, dry-operation, dry-transaction, business logic, workflow, service, Dry::Operation, step, compose operations.

0
installs
▌
Build API Slice · igmarin
Use when building a REST API, scaffolding API endpoints, or creating a JSON API resource in a Hanami 2.x application. Creates a new Hanami slice, generates controller actions, defines RESTful routes, writes request specs, and performs a code review. Handles JSON serialization, parameter validation, and error responses for API endpoints.

0
installs
▌
Slice Lifecycle · igmarin
Orchestrates the full Hanami slice lifecycle: creates the slice, tests it in isolation, reviews boundary design, and supports extraction from the app module. Use when building a new Hanami slice, auditing existing slices for bounded context violations, extracting monolithic code into a modular architecture, or enforcing slice generator conventions. Trigger terms: bounded context, Hanami module, modular architecture, slice boundaries, slice extraction, slice generator.

0
installs
▌
Review Code · igmarin
Use when reviewing Hanami 2.x code for quality and convention adherence — check Action responsibility at ≤~10 lines delegating business logic, verify DI via `include Deps[]` with no `Hanami.app["key"]` direct access, audit query locations ensuring all DB queries live in Repositories/Relations, inspect Repositories returning Entities not raw hashes, review Views receiving pre-fetched data only, check error handling logging+generic messages without exposing e.message, and assess test coverage for 400/404/422/500 paths. Triggers on phrases like 'review my Hanami code', 'check my action', 'code review', or 'dry-rb patterns'.

0
installs
▌
Add Table Column · igmarin
Use when adding a column, field, or new attribute to an existing table in Hanami 2.x, or when performing a database schema change such as altering a table. Chains write-migration, define-relation, define-entity, create-repository, and write-request-spec.

0
installs
▌
Create New Slice · igmarin
Use when creating a new Slice in Hanami 2.x — including when a user wants to add a slice, scaffold a slice, create a new Hanami module, or set up a bounded context. Chains create-slice, define-routes, configure-slice, inject-dependencies, and write-request-spec to generate the slice, configure routes, set up dependencies, and write smoke tests.

0
installs
▌
Write Action Spec · igmarin
Use when writing isolated RSpec unit specs for Hanami 2.x Actions — place spec under `spec/actions/` mirroring the action namespace with `type: :action` metadata, stub all `Deps[...]` dependencies via `instance_double` passed to `described_class.new(dep: stub)`, test both success (200/201) and error (422/500) paths, assert on `response.status`, `response.headers`, and action exposures without hitting the database or HTTP stack, and confirm the spec fails before implementing the Action. Generates specs with test doubles, status assertions, and params validation tests.

0
installs
▌
Decorate With Parts · igmarin
Use when creating View Parts for decorator-style logic in Hanami 2.x — define Part classes inheriting from `Hanami::View::Part`, delegate attributes to the wrapped value via `delegate :name, :email, to: :value`, expose data as a Part in Views with `expose :model, as: :model_part`, add presentation methods returning formatted strings or booleans (no HTML generation and no database queries in Parts), and access the raw underlying object via the `value` method when needed. Defines Part classes that encapsulate presentation logic, keeps templates free of complex formatting, and exposes them via the `expose` macro.

0
installs
▌
Write Request Spec · igmarin
Write failing RSpec request spec first then use `create-action` to implement — place at `spec/requests/` with `type: :request`, send JSON bodies with `.to_json` + `CONTENT_TYPE: application/json`, assert via `last_response.status` + `json_body`, confirm spec fails because action is unimplemented (not syntax error), test 404/422 error shapes, wrap DB specs in `"db transaction"` with ROM rollback. Covers Rack test helpers, params, response assertions, and JSON shape validation.

0
installs
▌
Add Background Jobs · igmarin
Use when integrating background jobs, async jobs, or background processing in Hanami 2.x — including Sidekiq integration, GoodJob worker setup, or any job queue configuration. Sets up background job providers, injects job-adapter dependencies into Hanami actions, creates job-triggering actions, and generates corresponding RSpec tests.

0
installs
▌
Build Crud Resource · igmarin
Use when implementing a full CRUD resource in Hanami 2.x, including when asked to scaffold, generate a resource, create a REST endpoint, or build a new API resource. Chains entity, relation, repository, action, view, write-request-spec, and review-code to build the complete data-to-HTTP pipeline.

0
installs
▌
Validation Contract · igmarin
Use when implementing validation with dry-validation contracts, schemas, or form/input/params validation in Hanami 2.x. Injects dependencies, validates request params using dry-validation contracts, handles monadic Success/Failure result patterns, and writes action specs. Chains inject-dependencies, validate-params, handle-result-pattern, and write-action-spec.

0
installs
▌
Manage Settings · igmarin
Use when managing Hanami 2.x application settings, app config, or environment variables (env vars). Covers defining typed settings with dry-configurable, setting defaults, validating enum values, reading .env files, and injecting settings into components via Hanami's container. Use when declaring typed environment variable declarations, accessing configuration in Actions or providers, or migrating from Rails config to Hanami 2.x settings.

0
installs
▌
Setup Authentication · igmarin
Use when implementing authentication in Hanami 2.x, including login, logout, signup, session management, password hashing, and protecting endpoints. Sets up login/logout flows, configures session-based or token-based auth, adds password hashing with bcrypt, and returns correct 401/403 responses for auth failures. Use when a user asks about auth, login, signup, JWT, sessions, passwords, or securing Hanami actions.

0
installs
▌
Configure Providers · igmarin bundle
Configure Hanami providers at `config/providers/[name].rb` using `Hanami.app.register_provider(:name) do [...] end` — define settings in `config/settings.rb` if the service needs configuration, implement lifecycle with `prepare` for requiring gems and `start` for instantiation using `target["settings"]` to access config (never hardcode credentials or use raw ENV), register with a descriptive key via `register("key", instance)`, and verify the provider boots without errors. Covers provider structure, settings integration, and boot lifecycle. Use when setting up a new provider, adding a service, or configuring ROM connections. Trigger words: provider, configure, ROM setup, external service, database connection, dry-system, boot, register component.

0
installs
▌
Review Slice Boundaries · igmarin
Reviews Hanami slice boundaries for violations — cross-slice coupling, shared internals, import leaks, provider leaks where a provider registers something that should be slice-scoped, and boundary design — producing findings with severity and concrete recommendations, every finding citing the specific file and line as evidence. Use when auditing slice architecture or preparing for extraction. Trigger words: review slice, slice boundaries, slice coupling, cross-slice, boundary review, slice audit, architecture review, bounded context.

0
installs
▌
Handle Result Pattern · igmarin bundle
Use when using the dry-monads Result pattern in Hanami 2.x — wrap outcomes in `Success(value)` or `Failure(error_object)`, chain operations with `Do notation` using `include Dry::Monads::Do.for(:call)` and `yield` inside the `call` method for sequential flows, inject the service object via `Deps["key"]` after registering it in a provider, handle results in Actions with pattern matching (`case result; in Success(v); ...; in Failure(e); ...; end`) rather than unsafe `value!` unwrapping, and model expected failures as data not exceptions. Covers bind/fmap chaining, and use in service objects registered in the DI container.

0
installs
▌
Create Validation Contract · igmarin bundle
Define type-safe validation contracts with `Dry::Validation::Contract` — declare expected fields and types in `schema do` blocks with `required(:field).filled(:string)` and `optional(:field)`, write custom predicates in `rule(:field) do` blocks returning `key.failure("message")` on invalid input, call the contract as the first step in an operation wrapping the result in `Success(result.to_h)` or `Failure(result.errors.to_h)`, and write tests asserting `.be_success` for valid input and `.be_failure` with specific `result.errors[:field]` assertions for invalid input, using TDD red-green-refactor. Use when validating request params, operation input, or any structured data. Trigger words: validation, contract, dry-validation, params, schema, Dry::Validation::Contract, validate input, type-safe, custom predicate.

0
installs

160 published skills · page 2 of 2