effect

Creates .opencode/references/effect-smol compliant Tyepescript services and workflows with ASP.NET Core MVC controllers and EF Core repositories.

4|1|Updated Mar 22, 2026
One-click install
npx skills add https://github.com/lgwanai/openforce --skill effect-lgwanai
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: effect
Source: https://github.com/lgwanai/openforce/tree/main/skills/effect
Command: npx skills add https://github.com/lgwanai/openforce --skill effect-lgwanai

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It helps you implement and evolve TypeScript services, schemas, and workflows using Effect v4 safely and consistently, avoiding outdated Effect v2/v3 patterns and reducing type and integration errors.

Core Features & Use Cases

  • Effect v4 / effect-smol alignment: Use the current v4 API surface as the single source of truth and match naming/style to the referenced repo.
  • Typed domain modeling: Prefer Schema (including branded schemas) and Schema.TaggedErrorClass for typed, explicit domain errors.
  • Workflow and service structure: Use Effect.gen(function* () { ... }) for multi-step workflows and keep HTTP handlers thin by moving business rules into services.
  • Tests that match runtime behavior: Use the repo’s Effect test helpers (testEffect, it.live) and keep dependency provisioning explicit and visible.

Quick Start

Use the effect skill to implement a new typed service workflow in this repo by first verifying the exact Effect v4 APIs in .opencode/references/effect-smol and then applying the project’s local composition and testing conventions.

Frequently Asked Questions about effect

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

FAQPage Schema
How do I implement typed errors in Effect v4?

Define domain errors in Effect v4 using `Schema.TaggedErrorClass` and `Schema` for branded data shapes to ensure explicit, type-safe error handling across your TypeScript services and workflows.

What is the best way to structure multi-step workflows with Effect v4?

Structure multi-step workflows in Effect v4 using `Effect.gen(function* () { ... })` to compose sequential effectful operations while keeping HTTP handlers thin and moving business rules into dedicated services.

How do I test Effect workflows with deterministic and live behaviors?

Test Effect workflows by using the repo's test helpers like `testEffect` and `it.live`, keeping dependency provisioning explicit and visible to accurately match runtime behavior during testing.

Why does my Effect schema integration fail with outdated API patterns?

Effect schema integration fails when applying outdated v2 or v3 patterns, so you must verify the exact current v4 API surface in `.opencode/references/effect-smol` to avoid type and integration errors.

Does this Effect v4 approach work with HTTP handler integration?

Yes, Effect v4 supports HTTP handler integration by keeping handlers thin and delegating business rules to typed services, allowing the HTTP layer to safely compose effectful workflows.

Do I need to verify APIs in effect-smol before adding domain schemas?

You must verify APIs in `.opencode/references/effect-smol` before adding domain schemas to ensure your typed TypeScript services align with the current v4 API surface and repo patterns.