effect-ts
Effect TS
Write idiomatic Effect code instead of promise-shaped TypeScript with Effect wrappers pasted on top.
Start
- Inspect the repo first:
package.json,tsconfig*, lockfile, existingeffect/@effect/*imports, and nearby tests. - Match the task to the smallest useful reference set below.
- If
effect-solutionsis installed, runeffect-solutions listandeffect-solutions show <topic>...before freehanding a pattern. - Follow local repo conventions before importing a new Effect pattern.
Read By Task
- Setup, install, tsconfig, or repo audit → references/setup-tooling.md
- Core application code → references/core-patterns.md
- HTTP, CLI, platform, or stream work → references/ecosystem-patterns.md
- Promise interop, framework boundaries, runtime issues, or gradual migration → references/adoption-runtime.md
Topic Map
effect-solutions show project-setup tsconfigfor bootstrap work.effect-solutions show basics services-and-layers data-modeling error-handling config testingfor core application code.effect-solutions show http-clients cli use-patternfor ecosystem and integration work.- Use
effect.website/docsfor deeper API detail, exhaustive module surfaces, and topics not yet covered here.
Defaults
- Use
Effect.genfor inline programs andEffect.fn("Name")for reusable named effectful functions. - Keep
Effect.run*at app edges, tests, workers, or framework adapters. - Put dependencies in services and layers, not hidden globals.
- Parse external data once at the boundary with
Schema, then pass typed values inward. - Model recoverable failures with tagged errors and narrow unions.
- Prefer test layers and
@effect/vitestover ad hoc mocks.
const loadUser = Effect.fn("loadUser")(function* (id: UserId) {
const repo = yield* UserRepo
return yield* repo.get(id)
})
const program = Effect.gen(function* () {
const input = yield* Schema.decodeUnknown(UserInput)(payload)
return yield* loadUser(input.id)
})
Source Order
- Use local project code and tests as the primary contract.
- Use
effect-solutionsfor opinionated patterns and tradeoffs. - Use
effect.websitefor the canonical API surface. - If a local clone of the Effect repo exists, grep it for real implementations before guessing.
class UserRepo extends Context.Tag("UserRepo")<
UserRepo,
{ readonly get: (id: UserId) => Effect.Effect<User, UserNotFound> }
>() {}
const UserRepoLive = Layer.succeed(UserRepo, {
get: (id) => Effect.gen(function* () {
const sql = yield* SqlClient.SqlClient
const rows = yield* sql`SELECT * FROM users WHERE id = ${id}`
if (rows.length === 0) return yield* new UserNotFound({ id })
return rows[0] as User
}),
})
Avoid
- Returning raw
Promisevalues from service methods unless the boundary forces it. - Calling
Effect.runPromisedeep inside domain code. - Using string errors when a tagged error should exist.
- Re-validating already parsed domain data in the core.
- Reaching for advanced abstractions before the simpler service / layer / schema model fits.
More from uinaf/skills
verify
Self-check your own completed change before handing off to `review` — the pre-review sanity pass. Use when you want to verify your change, test it end-to-end, run the repo's guardrails (lint, typecheck, tests, build), exercise the real surface with evidence, and catch obvious self-correctable issues you can fix in seconds. Produces a `ready for review` / `needs more work` / `blocked` verdict — never a ship decision (that's `review`'s job). If the repo cannot be booted or exercised reliably, hand off to `agent-readiness`. If you are auditing someone else's diff, branch, or PR, use `review` instead.
37docs
Update repo documentation and agent-facing guidance such as AGENTS.md, README.md, docs/, specs, plans, and runbooks. Use when code, skill, or infrastructure changes risk doc drift or when documentation needs cleanup or restructuring. Do not use for code review, runtime verification, or `agent-readiness` setup.
36viteplus
Migrate or align frontend repositories to the stock VitePlus workflow. Use when standardizing package or monorepo repos around `vp`, `voidzero-dev/setup-vp`, `vite-plus/test`, and VitePlus-native CI, test, packaging, and hook flows. Default to replacing direct package-manager and Vitest wiring with the VitePlus equivalents unless the repo has a proven exception.
29review
Independently audit existing code, diffs, branches, or pull requests using concern-specific reviewer personas and evidence. Use when triaging risk in a PR, deciding whether a change is safe to ship, or following up on a `verify` pass to make the call the builder cannot make on their own work. Produces a `ship it` / `needs review` / `blocked` verdict. Do not use to self-check a change you just authored; use `verify` for that.
23agent-readiness
Audit and build the infrastructure a repo needs so agents can work autonomously — boot scripts, smoke tests, CI/CD gates, dev environment setup, observability, and isolation. Use when a repo can't boot, tests are broken or missing, there's no dev environment, agents can't verify their work, or agents need human help to get anything done. Do not use for reviewing an existing diff or for documentation-only cleanup.
21skill-audit
Audit existing skills with Tessl scoring, metadata and trigger-coverage checks, repo conventions, and skill-authoring best practices. Use when creating or revising a skill, triaging weak self-activation, or comparing a skill against source-repo guidance such as `AGENTS.md`, `CLAUDE.md`, or repo rules, plus external skill guidance. Do not use to verify general application code or to rewrite unrelated docs.
19