skills/cats-mtl-typed-errors/SKILL.md
Scala typed errors with Cats MTL Raise/Handle and allow/rescue. Use for designing custom domain error types without EitherT, while keeping Cats Effect and ecosystem composition. Covers Scala 2/3 syntax and IO-only or F[_] usage.
npx skillsauth add alexandru/skills cats-mtl-typed-errorsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Raise[F, E] in functions that can raise errors.Handle.allow/rescue (Scala 3) or Handle.allowF (Scala 2) to introduce a scoped error capability and handle it like try/catch.IO[Either[E, A]] and avoid EitherT[IO, E, A]; pure functions returning Either[E, A] are fine at API boundaries.F[_] is optional: you can write IO-specific code or keep F[_] for polymorphism, depending on the project.Raise[F, E] (and Monad[F] or Applicative[F])..raise and return successful values with pure.Handle.allow (Scala 3) or Handle.allowF (Scala 2) to create a scope where raises are valid..rescue to handle each error case explicitly.E as the checked-exception channel in the function signature.Raise[F, E] in functions that can fail; use Handle[F, E] when you also need to recover.using and context functions with allow; type inference is significantly better.allowF and explicit implicit parameters; expect more braces and explicit types.Either[E, A] for parsing/validation and lift into F where needed.EitherT just to get a typed error channel; Cats MTL provides the capability without the stack.references/custom-error-types.md for detailed guidance, Scala 2/3 syntax, and rationale from the Typelevel article.development
Scala auto-derivation with Kindlings for Circe and PureConfig. Use when replacing circe-generic/circe-generic-extras or PureConfig generic derivation with Kindlings while keeping normal Circe JSON APIs and PureConfig loading/writing APIs.
development
Simplifies code for clarity without changing behavior. Use when code is working but overly complex, deeply nested, duplicated, or unclear.
development
Helps agents design and review Kotlin library APIs for Java consumers. Use when building Kotlin code intended for Java callers, shaping JVM signatures with @JvmName, @JvmOverloads, @JvmStatic, @JvmField, @Throws, @JvmRecord, nullability, records, and backward/binary compatibility rules.
tools
JSpecify nullness annotations for Java APIs and tooling. Use when adopting or migrating JSpecify annotations, designing null-safe Java signatures, fixing generic bounds and type-use placement, or interpreting Kotlin interop, annotation-processor, and tool-conformance behavior.