Skip to content
Back to skills

Scala Developer

ASecurity

Senior Scala developer using functional programming and Typelevel ecosystem. Use when writing Scala code, implementing Scala features, or working with sbt/bloop projects. Used as a part of the XP skill.

  • 3 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added June 5, 2026
developmentbashapi

Works with

  • api

Security analysis

A100/100

Scanned June 5, 2026

npx -y skills add channingwalton/dotfiles --skill scala-developer --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Scala Developer?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Scala Developer
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/channingwalton-scala-developer/badge)](https://www.skillsdirectory.com/skills/channingwalton-scala-developer)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: scala-developer
description: Senior Scala developer using functional programming and Typelevel ecosystem. Use when writing Scala code, implementing Scala features, or working with sbt/bloop projects. Used as a part of the XP skill.
---

# Scala Development

## Build Tool Selection

Prefer `devtool` when it is available — it auto-detects the project and wraps compile/lint/test, so you don't pick the runner by hand or risk using the wrong one:

- `devtool check` — compile + lint + test (run before committing)
- `devtool compile` — compile only
- `devtool test [pattern]` — run tests, optional filter

Drop to the underlying tool only when `devtool` is absent. Use bloop (faster incremental) if a `.bloop` directory exists, otherwise sbt; module name is `root` for non-modular projects:

```bash
bloop compile <module-name>
bloop test <module-name> -o "*<filename>*"

sbt compile
sbt "testOnly *SpecName*"
```

## Design Opinions

These reflect Channing's preferred style and may differ from what you'd produce by default:

- **Encapsulation over transparency**: prefer `class` with `private val` (or opaque types) over `case class` when a type has internal structure that shouldn't be part of its public API (e.g. a `Map` tracking counts, a buffer, an index). Reserve `case class` for value types where every field is meaningful to callers (e.g. `Book(title, author)`, `Config(host, port)`). The instinct to reach for `case class` by default leads to types that leak implementation details.

- **Typelevel ecosystem**: prefer cats, cats-effect, and fs2 over alternatives (e.g. ZIO, Akka). This is a codebase consistency choice, not a judgement call — mixing effect systems creates friction.

## Red Flags

- **Referencing a domain type's fields without confirming the shape** — even with the source in context. Assuming `Answer.Money.value.amount` when it was `Money(MonetaryAmount)` (`.amount`) cost a compile-fail cycle. Confirm the constructor/field shape from source before writing assertions or pattern matches.
- **A deliberate semantic divergence with no discriminating test.** When behaviour intentionally differs from the mirrored precedent or the happy path (scale-insensitive `BigDecimal` equality, instant-based `ZonedDateTime`, extension-stack resolution in a repeating row), write the test that *fails* if the divergence regresses. The reviewer caught these every time; the implementer did not write them first.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…