effect
Skill13 starsChanged 7 months agoMITView on GitHub
Opinionated guide for building production TypeScript applications with Effect v4. Use when implementing Effect workflows, services, layers, schemas, configuration, schedules, caches, streams, HTTP clients, or tests.
- Reads credentials
14 other projects use a version of this, 8 of them edited.
Adopted by
Most recently taken up by
- timmo001/notesedited, first seen Nov 8, 2026
- timmo001/contextedited, first seen Nov 8, 2026
- pauljasperdev/skillstheir own version, first seen Nov 1, 2026
- jpoehnelt/skillstheir own version, first seen Nov 1, 2026
- endalk200/skillsedited, first seen Oct 28, 2026
- itsyasirkhandev/skillsedited, first seen Oct 17, 2026
Used with
Projects with it also use humanizer, vercel-react-best-practices and 2 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
Microsoft AzureSkillhumanizer
Tone enforcement patterns for external-facing community responses
Also in 3 projects that use this
VercelSkillvercel-react-best-practices
React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.
Also in 3 projects that use this
GoogleSkillgrill-me
A relentless interview to sharpen a plan or design.
Also in 3 projects that use this
GoogleSkillcode-review
Adversarial systems, concurrency, memory-model, and architecture code review protocol. Use this skill whenever asked to review code, PRs, diffs, or branches in Filament.
Also in 3 projects that use this
Other versions14 projects use a version of this.
Word for word · 1
- rjdellecese/confect★ 381100% same
Edited · 8
- supabase/cli★ 2.5k92% same
- kitlangton/skills★ 32692% same
- mezotv/notra★ 25698% same
- usenotra/notra★ 25698% same
- itsyasirkhandev/skills★ 483% same
- timmo001/notes★ 292% same
- endalk200/skills★ 130% same
- timmo001/context★ 192% same
Wrote their own version · 5
- XiaomiMiMo/MiMo-Code★ 14ksame name
- akitaonrails/my-skills★ 283same name
- jpoehnelt/skills★ 23same name
- pengelbrecht/skills★ 1same name
- pauljasperdev/skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository16 other files it gives its agents.
- AGENTS.mdAGENTS.md
- examples/garfield/evals/fixtures/review-slice/AGENTS.mdAGENTS.md
- docs/public/llms.txtllms.txt
- openspec-apply-changeSkill
- openspec-archive-changeSkill
- openspec-exploreSkill
- openspec-proposeSkill
- commit-conventionsSkill
- effectSkill
- garfieldSkill
- garfieldSkill
- safe-deleteSkill
- safe-deleteSkill
- todo-hygieneSkill
- safe-deleteSkill
- skillet-authoringSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
23 rules. 2 are common, 8 are distinctive, and 13 are very specific to this project.
2
Common
Most of the 13 edited versions we read keep these.
8
Distinctive
This author's own choices. Worth a look.
13
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 11
Use current Effect v4 APIs and the production defaults in this skill.
- Distinctive: line 15
Check these before guessing:
- Distinctive: line 23
Read only the branch references that match the task.
- Distinctive: line 34
If a task spans several branches, read all matching files before editing.
- Very specific: line 40
Use Effect.fnUntraced only for internal helpers where stack-frame/span metadata is intentionally unnecessary.
- Very specific: line 41
Prefer Context.Service for application services when the codebase has not standardized on another current service-tag style.
- Very specific: line 45
Read runtime config through Config, not direct process.env access in application logic.
- Very specific: line 46
Use Schedule for retry, repeat, polling, pacing, and backoff policies.
- Very specific: line 47
Use Stream for effectful sources that emit many values over time and need pull, backpressure, interruption, or transformation.
- Distinctive: line 48
Prefer Effect HTTP client modules for outgoing HTTP in Effect applications when their typed errors, layers, and client transforms are …
- Distinctive: line 49
Prefer Effect-aware tests, explicit layers, and deterministic synchronization over sleeps.
- Very specific: line 50
Prefer decoders and schema.makeEffect(...) at untrusted boundaries.
- Common: line 80
Keep HTTP handlers thin: decode input, read context, call services, map typed errors to transport responses.
- Distinctive: line 81
Keep business rules in services or domain functions, not transport handlers.
- Common: line 84
Keep provider/network calls outside authoritative database transactions.
- Very specific: line 91
Do not use as any, non-null assertions, or unchecked casts to silence Effect typing problems.
- Very specific: line 92
Do not introduce Schema.Class or Schema.TaggedClass as default app data-modeling patterns.
- Very specific: line 93
Do not hand-roll _tag error classes when Schema.TaggedErrorClass fits.
- Distinctive: line 94
Do not use cause-level recovery when typed-error recovery is enough.
- Very specific: line 95
Do not use Layer.mergeAll(...) or provideMerge(...) as blind make-it-compile tools.
- Very specific: line 96
Do not hide required application authority, credentials, persistence, transports, or external services behind Context.Reference defaults.
- Very specific: line 97
Do not add arbitrary Effect.sleep(...) to tests when a deterministic synchronization primitive is available.
- Very specific: line 98
Do not hand-roll Map/TTL/prune caches or in-flight dedupe when effect/Cache fits.
“Common” is measured: kept by at least 6 in 10 of the 13 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Effect
Use current Effect v4 APIs and the production defaults in this skill. Established project conventions still take precedence unless the task is explicitly changing them.
Source Rule
Check these before guessing:
- the nearest
AGENTS.mdand any project-local Effect practices doc - the project-pinned
effectpackage source and version - current upstream Effect source when the installed package does not answer the question
Branch Chooser
Read only the branch references that match the task.
- Data models, schemas, brands, variants, optional keys, or decoders: read
references/SCHEMA.md. - Services, module surfaces, layers, runtime wiring, errors,
Effect.fn, or test services: readreferences/SERVICES_LAYERS.md. - Runtime config, env variables,
ConfigProvider, orlayerConfig: readreferences/CONFIG.md. - Retry, repeat, polling, backoff, jitter, rate-limit-aware policies, or pass loops: read
references/SCHEDULING.md. - Memoization, per-key TTL caches, deduplicating concurrent lookups, or request batching: read
references/CACHING.md. - Streams, event sources, async iterables, queues/pubsubs, pagination, backpressure, or stream consumers: read
references/STREAMS.md. - Outgoing HTTP calls, Effect HttpClient, status handling, or HTTP rate limiting: read
references/HTTP_CLIENTS.md. - Effect tests, time, sleeps, concurrency synchronization, or fakes: read
references/TESTING.md.
If a task spans several branches, read all matching files before editing.
Core Defaults
- Compose workflows with
Effect.gen(function* () { ... }). - Define public service methods and non-trivial internal service methods with
Effect.fn("Domain.operation"). - Use
Effect.fnUntracedonly for internal helpers where stack-frame/span metadata is intentionally unnecessary. - Prefer
Context.Servicefor application services when the codebase has not standardized on another current service-tag style. - Build real service implementations with
Layer.effect(Service, Effect.gen(...))and returnService.of({ ... }). - Model records with
Schema.Struct(...)plus a same-nameinterface. - Model typed Effect errors with
Schema.TaggedErrorClass. - Read runtime config through
Config, not directprocess.envaccess in application logic. - Use
Schedulefor retry, repeat, polling, pacing, and backoff policies. - Use
Streamfor effectful sources that emit many values over time and need pull, backpressure, interruption, or transformation. - Prefer Effect HTTP client modules for outgoing HTTP in Effect applications when their typed errors, layers, and client transforms are useful.
- Prefer Effect-aware tests, explicit layers, and deterministic synchronization over sleeps.
- Prefer decoders and
schema.makeEffect(...)at untrusted boundaries; reserve throwingschema.make(...)for trusted construction, and never use casts to skip validation.
Quick Selection Guide
- Ordinary object record:
Schema.Struct(...)plus same-nameinterface. - Scalar ID/value object: constrained branded schema.
- Internal workflow decision or state:
Data.TaggedEnum<...>plusData.taggedEnum<...>()constructors and exhaustive$match. - Reusable boundary-crossing tagged variant:
Schema.TaggedStruct(...)plus same-nameinterface. - Boundary-crossing tagged union:
Schema.TaggedUnion(...)with.cases,.guards, and.match. - External/custom discriminator such as
type:Schema.Struct({ type: Schema.tag("variant"), ... })plusSchema.toTaggedUnion("type")when union helpers are needed. - Expected typed failure:
Schema.TaggedErrorClass. - Unknown boundary payload:
Schema.decodeUnknownEffect(...). - Service boundary:
Context.Service<Service, Interface>()(...)plusLayer.effect(...)plusService.of(...). - Public or non-trivial internal service method:
Effect.fn("Domain.operation"). - Runtime configuration:
Configrecipes read in layers; override withConfigProviderin tests. - Event source:
Streamconsumed withStream.runForEach(...)and forked withEffect.forkScopedin the owning layer. - Queue-backed event source:
Queuefor the producer boundary,Stream.fromQueue(...)for consumers. - Broadcast event source:
PubSub/Stream.fromPubSub(...)orSubscriptionReffor latest-value state. - Polling worker:
runPass().pipe(Effect.repeat(Schedule.spaced(...))), with typed pass failures handled before repeat. - Retry transient operation:
Effect.retry(...)/Effect.retryOrElse(...)with a boundedSchedule. - Keyed lookup cache with TTL and concurrent-lookup dedupe: prefer
Cache.make(...)/ exit-awareCache.makeWith(...)when their lifecycle and eviction model fit. - Memoize a single effect result:
Effect.cached(...)/Effect.cachedWithTTL(...). - Batch N keys into one backend call (only when a real batch endpoint exists):
Effect.request(...)+RequestResolver. - HTTP request in an Effect application: prefer Effect
HttpClientplus request/response schema decoding. - HTTP transient retry:
HttpClient.retryTransient(...). - Time-sensitive test:
TestClock, not real sleeping. - Concurrent/background test synchronization:
Deferred,Queue,Latch,Ref, or explicit test hooks.
Boundary Rules
- Keep HTTP handlers thin: decode input, read context, call services, map typed errors to transport responses.
- Keep business rules in services or domain functions, not transport handlers.
- Wrap HTTP clients, SDKs, CLIs, and external integrations in named effects at adapter boundaries.
- Decode persisted rows with Schema or SQL-specific helpers when values are not trivially trusted.
- Keep provider/network calls outside authoritative database transactions.
- Catch or retry only when the current boundary has a truthful response.
- Retry only when the operation has proven idempotency.
- Let exhausted failures remain visible unless the boundary has a real fallback.
Do Nots
- Do not use
as any, non-null assertions, or unchecked casts to silence Effect typing problems. - Do not introduce
Schema.ClassorSchema.TaggedClassas default app data-modeling patterns. - Do not hand-roll
_tagerror classes whenSchema.TaggedErrorClassfits. - Do not use cause-level recovery when typed-error recovery is enough.
- Do not use
Layer.mergeAll(...)orprovideMerge(...)as blind make-it-compile tools. - Do not hide required application authority, credentials, persistence, transports, or external services behind
Context.Referencedefaults. - Do not add arbitrary
Effect.sleep(...)to tests when a deterministic synchronization primitive is available. - Do not hand-roll Map/TTL/prune caches or in-flight dedupe when
effect/Cachefits.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

