skills.rest
lambdasolver2
lambdasolver2COMMUNITY
Explore all skills by this author →
GitHub

effect-service-implementation

Implement Effect v4 services as fine-grained capabilities using namespace-module and layer composition patterns.

1|Updated Aug 24, 2026
Search Tags:#typescript#dependency injection#service design#effect#layer#capability pattern#context.service
One-click install
npx skills add https://github.com/lambdasolver2/opencode-effect-harness --skill effect-service-implementation-lambdasolver2
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: effect-service-implementation
Source: https://github.com/lambdasolver2/opencode-effect-harness/tree/main/packages/module-typescript/assets/skills/effect-service-implementation
Command: npx skills add https://github.com/lambdasolver2/opencode-effect-harness --skill effect-service-implementation-lambdasolver2

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Effect services often grow into monolithic classes that mix unrelated concerns, leak requirements into method signatures, and rely on removed v3 options, making them hard to test and compose. This Skill provides concrete patterns for designing focused, capability-based services in Effect v4. ## Core Features & Use Cases - Namespace-Module Pattern: Organize each service as a TypeScript namespace with an Interface, an empty Service tag class, and layer/defaultLayer exports built with Layer.effect and Service.of. - Capability Decomposition: Split monolithic services into single-concern capabilities (Gateway, Repository, Domain, Coordinator) that compose via Layer.mergeAll and Layer.provide. - Requirement Hygiene: Keep service method signatures at Requirements = never by capturing dependencies in Layer.effect closures, with guidance on optional capabilities via Effect.serviceOption and testing via Layer.succeed or Layer.mock. - Use Case: When refactoring a PaymentService that mixes handoff, refund, webhook, and reporting logic, apply this Skill to split it into PaymentGateway, PaymentRefundGateway, and PaymentWebhookGateway namespaces, each independently testable and wired through defaultLayer composition. ## Quick Start Ask the AI to implement a new Effect v4 service, such as a UserRepository with findById and create methods, following the namespace-module pattern with a defaultLayer.

Frequently Asked Questions about effect-service-implementation

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

FAQPage Schema
How do I implement an Effect v4 service with Context.Service?▼

Define a namespace containing an Interface type, an empty Service class extending Context.Service<Service, Interface>() with a tagged identifier, and a layer built with Layer.effect that returns Service.of({...}). Add a defaultLayer that wires dependencies via Layer.provide when the layer has unsatisfied requirements.

How to split a monolithic Effect service into smaller services?▼

Identify each cohesive capability and give it its own namespace, such as PaymentGateway, PaymentRefundGateway, and PaymentWebhookGateway. Each capability gets its own layer, and implementations are composed with Layer.mergeAll so different backends can support different capability sets.

Does Effect v4 still support accessors, effect, or dependencies options?▼

No, Effect v4 removed the accessors, effect, succeed, and dependencies options from Context.Service. Use yield* or .use()/.useSync() for access, Layer.effect or Layer.succeed externally for construction, and Layer.provide on the layer for dependency wiring.

Why should Effect service methods have Requirements of never?▼

Leaked requirements force every caller to supply dependencies the service should own. Capture dependencies in the Layer.effect closure via yield* and wire them with Layer.provide on defaultLayer, keeping method signatures clean with R = never.

How do I test an Effect service in isolation?▼

Provide a test implementation with Layer.succeed(Service, {...}) or the v4 shorthand Layer.mock(Service)({...}), then run the program with Effect.provide. Because each capability is a separate service, you can stub exactly one concern without touching others.

When should I use the class-statics pattern instead of the namespace pattern?▼

Use the class-statics pattern with make: and static layer/defaultLayer only for small services with at most a single simple dependency. For richer dependency graphs, prefer the namespace-module pattern, which keeps the service graph visible at yield* call sites and in defaultLayer composition.

Related Skills

Explore More Software Engineering Skills→
mpsuessermpsuesser
3

effect-error-handling

Implements typed error handling in Effect v4 using Schema.TaggedError, catch combinators, and Cause inspection.

Community
Advanced
agentxmagentxm
5

effect-layers

Construct and orchestrate composable service layers with dependency wiring and lifecycle management.

Official
Advanced
mpsuessermpsuesser
22

effect-observability

Instrument Effect TypeScript apps with logging, spans, and metrics.

Community
Advanced
ArabelaTsoArabelaTso
142

module-component-generator

Generate Python and Java modules from interface contracts and specifications.

Community
Advanced