Effect Patterns Hub: a pattern catalogue for Effect-TS with a CLI

The README is generated, and that shapes everything

The first thing the README tells you is that it is auto-generated. The file opens with a comment saying it is an auto-generated file, do not edit manually, that any manual edits will be overwritten when the pipeline runs, and that to modify it you run bun run admin pipeline or change the generator service at src/services/publish/generator.ts, with project information in ABOUT.md. A second warning block repeats the point for readers who arrive from the site. This is unusual and worth understanding before evaluating the project, because it tells you what kind of repository this is. It is not a library with a public API. It is a content pipeline: patterns live as mdx files under content/published/patterns, a pipeline validates and publishes them, and the README is one of the generated outputs alongside the website. The package.json confirms the shape, with a private package named effect-patterns-hub at version 0.14.0, a bun package manager pinned at 1.2.23, and workspaces over packages/*.

Patterns are graded by skill level and grouped by topic

The catalogue is organised into sixteen topics, and the table of contents runs from Getting Started and Core Concepts through Error Management, Resource Management, Concurrency, Streams, Scheduling, Domain Modeling, Schema, Platform, Building APIs, Making HTTP Requests, Building Data Pipelines, Testing, Observability and Tooling and Debugging. Each pattern entry carries a skill level and a one-line summary that states the effect of the technique rather than its syntax. The Getting Started section shows the shape of the thing: Why Effect compares Effect to Promise on type-safe errors, dependency injection and composability, then Hello World with Effect.succeed and Effect.runSync, then Effect.map, then handling a first error with Effect.fail and catchAll, then running multiple Effects in parallel with Effect.all, then retrying a failed operation with Effect.retry and a Schedule. The stated purpose of the repository is to help developers move from core concepts to advanced architectural strategies by focusing on the why behind the code, which is a different editorial stance from a reference manual.

A CLI for searching and installing patterns from the terminal

The piece that makes this more than a documentation site is the command line tool. The README calls it the way to search, browse and install patterns from your terminal:

bun add -g @effect-patterns/ep-cli
ep search "error handling"

The package.json registers two binaries, ep pointing at packages/ep-cli/dist/index.js and ep-admin at packages/ep-admin/dist/index.js, and there is a corresponding ep-admin command set for the pipeline side, with publish and validate subcommands wired to bun run ep:admin publish pipeline and bun run ep:admin publish validate. The install half of that command name is the interesting part, because a pattern you can install locally is a pattern that ends up in your project rather than in a browser tab. The repository also ships MCP_CONFIG.md and a deploy-mcp.sh script alongside .claude/, .cursor/, .windsurf/ and .cursorrules directories, which is the same set of integrations that coding agents read their local rules from.

Machine-readable rules for AI coding agents

The README asks directly whether you are looking for machine-readable rules for AI IDEs and coding agents, and points to its own AI Coding Rules section. The repository layout supports that reading: there is an .ai-cli-config.json at the root, a .claude/ directory, a .cursor/ directory, a .windsurf/ directory, a .cursorrules file, and separate AGENTS.md, CLAUDE.md and GEMINI.md files. There is also a generate:skills script, bun run scripts/generate-skills.ts, which suggests the patterns are compiled into skill files for agents as well as rendered as pages for people. The scripts/ directory holds the publishing pipeline, with publish/validate.ts and publish/generate.ts behind the validate:simple and generate scripts. So the same content has two consumers: a human browsing the site, and an agent reading local rules. That dual output is the most distinctive thing about the project.

EffectTalk.dev is where the patterns are read and run

The README points at a companion site built on the repository. EffectTalk.dev lets you browse all 300+ patterns, take guided learning tours, and run code examples in the browser, with links to a start page for the guided tour, a patterns index and a welcome post. The count of more than 300 patterns is the headline number in the README, and it is worth reading carefully because it describes the state of the site rather than a versioned release. The value of running examples in the browser is obvious for a library whose type-level behaviour is the hard part. You can see what Effect.all does with the error and success channels without setting up a TypeScript project and a bundler, and for a library where the difference between a typed error channel and an untyped throw is the entire point, being able to compare two runs side by side is more informative than any prose description.

The content is generated from a database, not edited in place

The infrastructure tells you how the knowledge base is built. There is a docker-compose.yml with a postgres:16-alpine service named effect-patterns-db, with the standard postgres credentials and a database called effect_patterns, exposed on port 5432 and given a healthcheck that runs pg_isready every ten seconds. There is a drizzle.config.ts, so the schema is managed with Drizzle, and a set of init-test-db.sh and test-db-simple.ts scripts for the test database. The pipeline state lives in .pipeline-state.json, and there is an .ep-installed.json, which is presumably the record of what the CLI has installed into a given project. The consequence for a reader is that the source of truth is the database plus the pattern mdx files, and the README is a projection of it. That also explains why the README says not to edit it manually, and why there is an admin pipeline rather than a hand-maintained index.

A low-traffic repository with a conventional release line

On maintenance, the repository is not archived and the last push was on 2026-06-15, which is a little over four months ago. The releases tell a similar story. v0.12.2 on 2026-02-11, v0.12.4 and v0.13.0 both on 2026-02-27, and the package.json version at 0.14.0, so the version has moved past the newest tag. The naming of one release is a useful clue about what these releases are for: v0.12.2 is described as populating all DB tables and removing jobs tables, which is a content pipeline change rather than a change to any Effect-TS pattern. The licence is MIT with the LICENSE file at the root. There is a SECURITY.md and a CHANGELOG.md, and the project uses Biome for formatting and linting via biome.json, with Vitest for tests in a workspace configuration. The repository also carries a turbo.json for the build pipeline even though the package manager is bun, which tells you the workspace layout is shared with other projects built the same way.

Editorial conclusion

Adopt Effect Patterns Hub if you are working in Effect-TS and want worked examples with the reasoning behind them rather than API documentation, and if you would like the same patterns available to your team and to a coding agent. Do not adopt it expecting a stable library to depend on, because the README is generated by a publishing pipeline and the repository is a content pipeline with a CLI attached rather than a package with a compatibility promise. Before you commit, read the Getting Started and Core Concepts sections first, install the CLI with bun add -g @effect-patterns/ep-cli, and check the pattern count in EffectTalk against what the site actually covers today.

Frequently asked questions

Official sources

1. License: MIT
2. PaulJPhilp/EffectPatterns on GitHub
3. Project website
4. README
5. Releases