---
name: Effect
slug: effect
category: AI Engineering
description: "Effect helps you work with Effect v4 and effect-smol TypeScript code in this repo. Use it when implementing services, schemas, workflows, and tests that follow the project's local patterns."
github: "https://github.com/shobcoder/shob/tree/main/.shob/skills/effect"
language: TypeScript
stars: 582
forks: 0
install: "npx degit https://github.com/shobcoder/shob/tree/main/.shob/skills/effect ~/.claude/skills/effect"
installs_to: ~/.claude/skills/effect
source_path: .shob/skills/effect/SKILL.md
collection_size: 14
category_size: 2451
collection_url: "https://dirskills.com/collections/shobcoder/shob"
added: 2026-08-25T05:13:54.634Z
last_synced: 2026-08-25T05:13:54.634Z
canonical_url: "https://dirskills.com/skills/effect"
---

# Effect

Effect helps you work with Effect v4 and effect-smol TypeScript code in this repo. Use it when implementing services, schemas, workflows, and tests that follow the project's local patterns.

**Install:**

```bash
npx degit https://github.com/shobcoder/shob/tree/main/.shob/skills/effect ~/.claude/skills/effect
```

## README

# Effect

This codebase uses Effect for typed, composable TypeScript services, schemas, and workflows.

## Source Of Truth

Use the current Effect v4 / effect-smol source, not memory or older Effect v2/v3 examples.

1. If `.shob/references/effect-smol` is missing, clone `https://github.com/Effect-TS/effect-smol` there. Do this in the project, not in the skill folder.
2. Search `.shob/references/effect-smol` for exact APIs, examples, tests, and naming patterns before answering or implementing Effect-specific code.
3. Also inspect existing repo code for local house style before introducing new patterns.
4. Prefer answers and implementations backed by specific source files or nearby repo examples.

## Guidelines

- Prefer current Effect v4 APIs and project-local patterns over old blog posts, examples, or package-memory guesses.
- Use `Effect.gen(function* () { ... })` for multi-step workflows.
- Use `Effect.fn("Name")` or `Effect.fnUntraced(...)` for named effects when adding reusable service methods or important workflows.
- Prefer Effect `Schema` for API and domain data shapes. Use branded schemas for IDs and `Schema.TaggedErrorClass` for typed domain errors when modeling new error surfaces.
- Keep HTTP handlers thin: decode input, read request context, call services, and map transport errors. Put business rules in services.
- In Effect service code, prefer Effect-aware platform abstractions and dependencies over ad hoc promises where the surrounding code already does so.
- Keep layer composition explicit. Avoid broad hidden provisioning that makes missing dependencies hard to see.
- In tests, prefer the repo's existing Effect test helpers and live tests for filesystem, git, child process, locks, or timing behavior.
- Do not introduce `any`, non-null assertions, unchecked casts, or older Effect APIs just to satisfy types.
- Do not answer from memory. Verify against `.shob/references/effect-smol` or nearby code first.

## Testing Patterns

- Use `testEffect(...)` from `packages/shob/test/lib/effect.ts` for tests that exercise Effect services, layers, runtime context, scoped resources, or platform integrations.
- Use `it.live(...)` for filesystem, git repositories, HTTP servers, sockets, child processes, locks, real time, and other live platform behavior.
- Run tests from package directories such as `packages/shob`; never run package tests from the repo root.
- Prefer explicit test layers over ad hoc managed runtimes. Keep dependency provisioning visible in the test file.
- Use scoped fixtures and finalizers for resources that must be cleaned up, including temporary directories, flags, databases, fibers, servers, and global state.