effect

Name: effect
Author: shobcoder

578stars0forks

How to install effect?

shobcoder/shob/effect

$npx -y skills add shobcoder/shob --skill effect

Installs into the current project.

Summary

Work with Effect v4 / effect-smol TypeScript code in this repo

Files · 1

View on GitHub

SKILL.md

1	# Effect
2
3	This codebase uses Effect for typed, composable TypeScript services, schemas, and workflows.
4
5	## Source Of Truth
6
7	Use the current Effect v4 / effect-smol source, not memory or older Effect v2/v3 examples.
8
9	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.
10	2. Search `.shob/references/effect-smol` for exact APIs, examples, tests, and naming patterns before answering or implementing Effect-specific code.
11	3. Also inspect existing repo code for local house style before introducing new patterns.
12	4. Prefer answers and implementations backed by specific source files or nearby repo examples.
13
14	## Guidelines
15
16	- Prefer current Effect v4 APIs and project-local patterns over old blog posts, examples, or package-memory guesses.
17	- Use `Effect.gen(function* () { ... })` for multi-step workflows.
18	- Use `Effect.fn("Name")` or `Effect.fnUntraced(...)` for named effects when adding reusable service methods or important workflows.
19	- 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.
20	- Keep HTTP handlers thin: decode input, read request context, call services, and map transport errors. Put business rules in services.
21	- In Effect service code, prefer Effect-aware platform abstractions and dependencies over ad hoc promises where the surrounding code already does so.
22	- Keep layer composition explicit. Avoid broad hidden provisioning that makes missing dependencies hard to see.
23	- In tests, prefer the repo's existing Effect test helpers and live tests for filesystem, git, child process, locks, or timing behavior.
24	- Do not introduce `any`, non-null assertions, unchecked casts, or older Effect APIs just to satisfy types.
25	- Do not answer from memory. Verify against `.shob/references/effect-smol` or nearby code first.
26
27	## Testing Patterns
28
29	- Use `testEffect(...)` from `packages/shob/test/lib/effect.ts` for tests that exercise Effect services, layers, runtime context, scoped resources, or platform integrations.
30	- Use `it.live(...)` for filesystem, git repositories, HTTP servers, sockets, child processes, locks, real time, and other live platform behavior.
31	- Run tests from package directories such as `packages/shob`; never run package tests from the repo root.
32	- Prefer explicit test layers over ad hoc managed runtimes. Keep dependency provisioning visible in the test file.
33	- Use scoped fixtures and finalizers for resources that must be cleaned up, including temporary directories, flags, databases, fibers, servers, and global state.

People who liked this also viewed

6 picks

Type

paperclip-create-agentCreate new agents in Paperclip with governance-aware hiring. Use when you need to inspect adapter configuration options, compare existing agent configs, draft a new agent prompt/config, and submit a hSkillsJul 2026157k5
subagent-driven-developmentUse when executing implementation plans with independent tasks in the current sessionSkillsJul 2026154k259k
dispatching-parallel-agentsUse when facing 2+ independent tasks that can be worked on without shared state or sequential dependenciesSkillsJul 2026143k259k
browser-act-skill-forgeForges reusable Skill packages (SKILL.md + scripts) from website exploration via browser-act — no re-exploration later. Use when: user wants a reusable Skill for any website, needs to understand a sitSkillsJul 202685k4.6k
wizardGenerate an interactive bash wizard that walks a human through a manual procedure — third-party setup, a one-off migration, an A→B state transition — opening URLs, capturing values, confirming each stSkillsJul 202675k182k
wonda-cliUsing the Wonda CLI to generate images, videos, music, and audio from the terminal — plus LinkedIn, Reddit, and X/Twitter research and automationSkillsJul 202666k137

effect

578stars0forks

View on GitHub

How to install effect?

shobcoder/shob/effect

$npx -y skills add shobcoder/shob --skill effect

Installs into the current project.

Summary

Work with Effect v4 / effect-smol TypeScript code in this repo

Files · 1

View on GitHub

SKILL.md

1	# Effect
2
3	This codebase uses Effect for typed, composable TypeScript services, schemas, and workflows.
4
5	## Source Of Truth
6
7	Use the current Effect v4 / effect-smol source, not memory or older Effect v2/v3 examples.
8
9	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.
10	2. Search `.shob/references/effect-smol` for exact APIs, examples, tests, and naming patterns before answering or implementing Effect-specific code.
11	3. Also inspect existing repo code for local house style before introducing new patterns.
12	4. Prefer answers and implementations backed by specific source files or nearby repo examples.
13
14	## Guidelines
15
16	- Prefer current Effect v4 APIs and project-local patterns over old blog posts, examples, or package-memory guesses.
17	- Use `Effect.gen(function* () { ... })` for multi-step workflows.
18	- Use `Effect.fn("Name")` or `Effect.fnUntraced(...)` for named effects when adding reusable service methods or important workflows.
19	- 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.
20	- Keep HTTP handlers thin: decode input, read request context, call services, and map transport errors. Put business rules in services.
21	- In Effect service code, prefer Effect-aware platform abstractions and dependencies over ad hoc promises where the surrounding code already does so.
22	- Keep layer composition explicit. Avoid broad hidden provisioning that makes missing dependencies hard to see.
23	- In tests, prefer the repo's existing Effect test helpers and live tests for filesystem, git, child process, locks, or timing behavior.
24	- Do not introduce `any`, non-null assertions, unchecked casts, or older Effect APIs just to satisfy types.
25	- Do not answer from memory. Verify against `.shob/references/effect-smol` or nearby code first.
26
27	## Testing Patterns
28
29	- Use `testEffect(...)` from `packages/shob/test/lib/effect.ts` for tests that exercise Effect services, layers, runtime context, scoped resources, or platform integrations.
30	- Use `it.live(...)` for filesystem, git repositories, HTTP servers, sockets, child processes, locks, real time, and other live platform behavior.
31	- Run tests from package directories such as `packages/shob`; never run package tests from the repo root.
32	- Prefer explicit test layers over ad hoc managed runtimes. Keep dependency provisioning visible in the test file.
33	- Use scoped fixtures and finalizers for resources that must be cleaned up, including temporary directories, flags, databases, fibers, servers, and global state.

People who liked this also viewed

6 picks

Type