agentsclimarketplace
Sign in

Build scala service

Skill gaelic-ghost/socket/plugins/server-side-jvm/skills/build-scala-service

Implement and maintain idiomatic Scala backend services, including immutable data modeling, algebraic data types, options/eithers, effect or future-based async boundaries, framework routing, module design, tests, and functional service structure.From its SKILL.md

Install
npx -y skills add gaelic-ghost/socket --skill build-scala-service

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its file declares

Copied from the file, not written here

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

5.2 KB, 984 tokens by cl100k_base, as published. Nobody here has run it

Build Scala Service

Purpose

Implement Scala backend behavior with Scala as a first-class JVM path.

The practical decision is how to use immutable data, explicit effects or futures, clear module boundaries, and focused tests without translating Java service patterns into Scala syntax.

When To Use

  • Use this skill when the repository is Scala-first and the task changes backend behavior.
  • Use this skill when the user asks for functional JVM backend work and repo context does not point elsewhere.
  • Use this skill when choose-service-shape routes implementation to Scala.
  • Use Java guidance instead for Java-dominant backend modules, and Android guidance for Android app/platform work.

Source Check

Use repo-local JVM files, checked-out dependency sources, Dash MCP or Dash HTTP for installed JVM docsets, and then official or canonical documentation when Dash/local coverage is missing or stale:

Use framework documentation for framework-specific behavior. Translate documentation rules into concrete code, test, or validation decisions.

Implementation Workflow

  1. Inspect the existing Scala shape:
    • Scala version
    • SBT, Gradle, or Maven project layout
    • package and module names
    • framework entry points
    • effect model, future model, or synchronous style
    • test framework
    • formatting and lint expectations
  2. Model data functionally:
    • prefer immutable case classes for product data
    • use sealed traits or enums for closed alternatives
    • use Option for expected absence
    • use Either, validated values, or the repo's effect error channel for recoverable domain errors
    • avoid null unless interoperating with Java or a framework API that requires it
  3. Keep behavior composable:
    • write small pure functions for domain transformations where practical
    • keep routing, request decoding, and response encoding at the edge
    • pass dependencies explicitly through the repository's existing pattern
    • avoid abstracting with typeclasses unless the abstraction has more than one real use or matches local style
  4. Preserve the async/effect model:
    • use Future if the project is Future-based
    • use the repository's established effect system when one exists
    • do not introduce Cats Effect, ZIO, Akka/Pekko, or another runtime for one feature
    • keep resource acquisition, cancellation, retries, and timeouts explicit around external dependencies
  5. Add focused tests:
    • test pure domain behavior directly
    • add route or integration tests when serialization, auth, persistence, or framework behavior changed
    • preserve ScalaTest, MUnit, Weaver, or repository-selected style

Framework Boundaries

Preserve the existing framework unless the user asks for a framework decision.

  • Keep http4s, ZIO HTTP, Akka/Pekko, Play, Spring, or framework-specific code at the service edge.
  • Keep domain and validation code framework-light when it will be reused or tested independently.
  • Do not make one framework's module structure the default for another framework.

Validation

Use server-side-jvm:build-tooling-workflow to choose exact commands.

Common validation shapes:

  • SBT module: sbt module/test
  • SBT full check: sbt test
  • Gradle Scala module: ./gradlew :module:test
  • Maven Scala module: mvn -pl module -am test

Run broader validation before commit, push, PR, release, or cross-module behavior changes.

Output Shape

Return:

  1. Changed behavior: the Scala service behavior or API changed.
  2. Functional boundary: pure domain, effectful service, route edge, persistence adapter, config, or test.
  3. Data model: case classes, sealed traits/enums, options, eithers, validated values, or existing convention.
  4. Effect model: synchronous, Future, Cats Effect, ZIO, Akka/Pekko, or existing runtime.
  5. Validation: exact build and test commands and results.

Guardrails

  • Do not treat Scala as Java with different syntax.
  • Do not introduce an effect system, framework, or typeclass abstraction without a real project reason.
  • Do not use null or exceptions for ordinary domain flow unless local conventions require it.
  • Do not convert Java modules to Scala unless the user asks.
  • Do not make Android app/platform concerns part of this skill.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most data backend skills give in 984 tokens

Counted across 229 of the 229 authors here whose files we hold, read 2026-08-07

  • Separate business logic into service layersin 22 of 229, across 15 files
  • Retry failures with exponential backoffin 21 of 229, across 14 files
  • Select only needed database columnsin 20 of 229, across 13 files
  • Abstract data access into repository classesin 19 of 229, across 12 files
  • Use centralized error handlersin 17 of 229, across 10 files
  • Use AsNoTracking for read-only queriesin 16 of 229, across 4 files
  • Use async/await for all I/O operationsin 16 of 229, across 5 files
  • Implement structured loggingin 15 of 229, across 4 files
  • Use dependency injection for all servicesin 14 of 229, across 2 files
  • Use resource-based URLs for REST APIsin 13 of 229, across 7 files
  • Invalidate cache after data changesin 13 of 229, across 9 files
  • Use a dependency injection containerin 12 of 229, across 4 files

Said here and by no other author read

  • use repo-local JVM files first for source checks
  • inspect the existing scala project shape
  • use sealed traits or enums for closed alternatives
  • use Option for expected absence
  • keep routing and serialization at the edge
  • preserve the repository's established effect or future model

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,861. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.