effect-service-implementation

Implement composable Effect v4 services with namespace modules and Layer.effect dependency wiring.

22|1|Updated Apr 14, 2026
One-click install
npx skills add https://github.com/mpsuesser/pi-effect-harness --skill effect-service-implementation
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: effect-service-implementation
Source: https://github.com/mpsuesser/pi-effect-harness/tree/main/harnesses/effect/skills/effect-service-implementation
Command: npx skills add https://github.com/mpsuesser/pi-effect-harness --skill effect-service-implementation

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It solves the problem of building large, monolithic or poorly separated Effect codebases by guiding you to implement each capability as a small, composable Effect service with clear dependency wiring.

Core Features & Use Cases

  • Namespace-module service structure: Keep Interface, Service tag, layer, and (optionally) defaultLayer together for an explicit service graph.
  • Dependency-safe construction: Use Layer.effect with captured dependencies via yield*, while ensuring service method Requirements stay as never (no requirement leakage).
  • Production composition by default: Build defaultLayer via Layer.provide so wiring is straightforward, testable, and maintainable.
  • Capability-based design: Split features into single-responsibility services like repositories, gateways, coordinators, and run-state.
  • Testing-friendly layers: Promote implementation details into layers so you can swap behavior using Layer.succeed or Layer.mock.

Quick Start

Implement your capability as a namespace that defines an Interface, an empty Context.Service tag, a layer built with Layer.effect and Effect.gen, and a defaultLayer that wires in dependencies with Layer.provide only when needed.

Frequently Asked Questions about effect-service-implementation

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I structure composable Effect services to avoid monolithic designs?

Prevent requirement leakage in Effect service method signatures by capturing dependencies with yield* inside Layer.effect and returning implementations via Service.of, ensuring method Requirements stay as never.

What is the best way to wire dependencies in Effect-ts service layers?

Split features into single-responsibility Effect services such as repositories, gateways, coordinators, and run-state to achieve capability-based design and maintain a clear, explicit service graph.

Can I swap Effect service implementations for testing without changing production code?

Use Effect.fn with namespace-prefixed span names when implementing Effect v4 services to maintain organized tracing and ensure proper service construction across coordinator-style lifecycle services.

Why do my Effect service method signatures leak requirements into the call site?

Effect service method signatures leak requirements when dependencies are not properly captured within Layer.effect using yield*, so ensure implementations are returned via Service.of to keep Requirements as never.