MCPInstall

effect-v4

Write, review, or upgrade Effect v4 code in the Composio CLI, cli-keyring, and json-schema-to-effect-schema packages, all pinned exactly to effect@4.0.3 — Context.Service and explicit layers, Schema.TaggedError and typed recovery, the effect/cli command surface, and the vendored effect source oracle. Use when writing or reviewing Effect v4 code, answering a v4 API question, working in effect/cli, defining a Context.Service service, modeling an error with Schema.TaggedError, bumping the Effect pins, or verifying an unfamiliar API against ts/vendor/effect. Do not use for CLI command UX/wiring design (use cli-command) or CLI E2E tests (use cli-e2e).

Installs
53
Last 24h
—
Trending rank
—
Security
Not audited

Install

Works with every agent the skills CLI supports.

npx skills add https://github.com/composiohq/composio --skill effect-v4
  1. 01

    Install

    Run the command in your project. The CLI asks which agents to install for.

  2. 02

    Describe the task

    Ask your agent for something this skill covers. It loads effect-v4 automatically when relevant.

  3. 03

    Review the result

    The agent follows the SKILL.md steps, scripts and references bundled with the skill.

SKILL.md

The instructions your agent reads when the skill is triggered.

Effect v4

The CLI, @composio/cli-keyring, and @composio/json-schema-to-effect-schema run on Effect v4. Every claim below is grounded in the migrated source, not memory of v3.

Exact version matrix

effect, @effect/platform-bun, and @effect/vitest are pinned to the same exact 4.0.3 — never ^, @next, or a mismatched version across packages. @effect/cli and @effect/platform no longer exist as dependencies; their surfaces are consolidated into effect and effect/*. See versions.json for the full matrix (also typescript, vitest).

Read next

  • references/core-patterns.md — services, layers, typed errors, Schema, choosing between Effect.gen and Effect.fn, Option combinators in place of isSome ternaries, driving time in tests with TestClock (fork, adjust until the fiber settles, join) instead of it.live, and the v3→v4 rename table (labeled historical, for recognizing stale patterns).
  • references/cli-surface.md — effect/cli: Command, Flag, Argument, GlobalFlag, CliConfig, the custom CliOutput.Formatter, and the runner's double-print rule.
  • references/upgrade-workflow.md — procedure for bumping to a newer release.

Code excerpts in those references are short quotes from real, currently-compiling repo files (path cited at each excerpt) — not standalone examples. The compile-checked source of truth is always the cited file itself; when it and a reference disagree, trust the file and fix the reference.

Non-negotiables

  • Effect.gen(function* () {...}) for effect values — the dominant form, including named module consts — and (params) => Effect.gen(...) for parameterized helpers. Effect.fn(...) is the function form whose effects carry stack-frame annotations (its optional name string adds a per-call tracing span), worth it for service members and combinator callbacks that should be attributable in error reports. All forms re-run their body per execution. See "Effect.gen vs Effect.fn" in core-patterns.
  • Define services with Context.Service and an explicit static readonly Default/layer layer built with Layer.succeed/Layer.effect/Layer.provide. V4 does not generate a layer for you.
  • Model expected failures with Schema.TaggedError (or a plain Data.TaggedError when no Schema fields are needed) and recover with Effect.catchTag/catchTags/Match, never manual _tag string comparisons.
  • Wrap fallible Promises with Effect.tryPromise({ try, catch }); Effect.promise turns rejection into a defect. No async/await or try/catch inside Effect workflows — ESLint bans them in ts/packages/cli/src.
  • Treat every remembered v3 package name and API as wrong until verified against ts/vendor/effect (read-only source oracle — never edit or import from it) and the installed effect@4.0.3 typings. Source may be ahead of the published package; the compiler is the compatibility gate.

Verification

pnpm typecheck
pnpm --filter @composio/cli test

Run pnpm validate:agent-skills and pnpm validate:skill-routing after editing this skill or its descriptions, and compile the TypeScript blocks in this skill and in typescript-testing/references/effect-v4-cli.md against the pinned packages with:

node .agents/skills/effect-v4/scripts/check-examples.mjs

Blocks that quote repo files with unresolvable imports carry a no-check fence info string.

FAQ

What does the effect-v4 skill do?

Write, review, or upgrade Effect v4 code in the Composio CLI, cli-keyring, and json-schema-to-effect-schema packages, all pinned exactly to effect@4.0.3 — Context.Service and explicit layers, Schema.TaggedError and typed recovery, the effect/cli command surface, and the vendored effect source oracle. Use when writing or reviewing Effect v4 code, answering a v4 API question, working in effect/cli, defining a Context.Service service, modeling an error with Schema.TaggedError, bumping the Effect pins, or verifying an unfamiliar API against ts/vendor/effect. Do not use for CLI command UX/wiring design (use cli-command) or CLI E2E tests (use cli-e2e).

How do I install effect-v4?

Run npx skills add https://github.com/composiohq/composio --skill effect-v4 in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/effect-v4/ (personal) or .claude/skills/effect-v4/ (project).

Which AI agents can use effect-v4?

Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.

Is effect-v4 safe to install?

No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.

Who maintains effect-v4?

It is published by composiohq in composiohq/composio. It has 53 recorded installs.

More from composiohq/composio

View all →

composio

composiohq/composio

Route and complete Composio work across Composio For You and Composio Platform. Use when the user mentions Composio; wants an agent to use apps such as Gmail, Slack, GitHub, Notion, Calendar, or Linear; needs first-time setup, an SDK or MCP integration, CLI operation, migration guidance, current documentation, or help diagnosing a connection or tool call.

typescript-testing

composiohq/composio

Select and run TypeScript SDK verification for packages, examples, type checks, linting, builds, Vitest suites, Effect v4 CLI tests, and runtime E2E tests. Use when adding tests, diagnosing TypeScript CI, choosing a focused test command, validating TypeScript package changes, or writing/porting CLI tests against effect@4.0.3 and @effect/vitest. Do not use for Python-only checks.

Testing & QA135 installs

bug-fixing

composiohq/composio

Fix defects in the Composio SDK repository with focused reproduction, root-cause analysis, regression tests, and narrow verification. Use when the user reports a bug, failing test, CI regression, runtime defect, or incorrect SDK behavior. Do not use for new feature design or broad refactors.

cli-command

composiohq/composio

Design, implement, or review Composio CLI commands under ts/packages/cli using Effect, effect/cli, services, output conventions, configuration and environment variables, and local vendor references. Use for CLI command UX, command wiring, service changes, or CLI source edits. Do not use for CLI E2E-only work; use cli-e2e there.

Testing & QA131 installs

typescript-sdk

composiohq/composio

Implement or modify TypeScript SDK behavior in @composio/core or shared TypeScript packages, including tools, toolkits, sessions, auth configs, connected accounts, modifiers, and generated SDK surfaces. Use for TS runtime/API work; pair with typescript-testing for verification and cross-sdk-parity when Python must match.

python-testing

composiohq/composio

Select and run Python SDK verification with nox, Makefile targets, Ruff, mypy, pytest markers, sanity tests, type inference checks, and build checks. Use when adding Python tests, diagnosing Python CI, or validating Python SDK/provider changes. Do not use for TypeScript-only checks.

Testing & QA130 installs

Popular testing & qa skills

View category →

tdd

mattpocock/skills

Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.

Testing & QA1.2M installs

grilling

mattpocock/skills

Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.

Testing & QA996.2K installs

migrate-to-shoehorn

mattpocock/skills

Migrate test files from as type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace as in tests, or needs partial test data.

Testing & QA484.1K installs

run-train

lllllllama/rigorpilot-skills

Rigor Train skill for deep learning research repositories. Use when a documented or selected training command should be run conservatively for startup verification, short-run verification, full kickoff, or resume, with command, config, seed, log, checkpoint, status, and metric evidence written to standardized trainoutputs/. Do not use for environment setup, exploratory sweeps, speculative idea implementation, or end-to-end orchestration.

Testing & QA337.8K installs

test-driven-development

obra/superpowers

Use when implementing any feature or bugfix, before writing implementation code

Testing & QA261.8K installs

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work

Testing & QA216.8K installs