Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add mpsuesser/pi-effect-harness --skill effect-incremental-migrationgit clone --depth 1 https://github.com/mpsuesser/pi-effect-harnessWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/mpsuesser/pi-effect-harness/effect-incremental-migration)<a href="https://agentmods.dev/skills/mpsuesser/pi-effect-harness/effect-incremental-migration"><img src="https://agentmods.dev/badge/skills/mpsuesser/pi-effect-harness/effect-incremental-migration.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00052 | $0.02878 |
| Opus 5 | $0.00026 | $0.01439 |
| Sonnet 5 | $0.00010 | $0.00576 |
| Haiku 4.5 | $0.00005 | $0.00288 |
Grade A, and why
effect-incremental-migration scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 7d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 363 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Incremental Migration Skill
This skill provides a step-by-step template for converting existing async/Promise-based modules to Effect services. Preserve backward compatibility only where you still have non-Effect callers. The main goal is to move Effect callers onto yield* SomeService.Service early so dependency edges become explicit in the code and in the layer graph.
Effect Source Reference
The Effect v4 source is available at ~/.cache/effect-v4/.
Browse and read files there directly to look up APIs, types, and implementations.
Reference this for:
- Context source:
packages/effect/src/Context.ts - Layer source:
packages/effect/src/Layer.ts - ManagedRuntime source:
packages/effect/src/ManagedRuntime.ts - Migration guide:
MIGRATION.md - Effect source:
packages/effect/src/
The 7-Step Migration Template
Step 1: Define the Service Interface
Extract a named Interface type with Effect-returning methods. Keep parameter and return types identical to the original module — only swap Promise<T> for Effect.Effect<T, E>.
import type { Effect } from 'effect';
export namespace MyModule {
export interface Interface {
readonly get: (id: string) => Effect.Effect<Item, MyModuleError>;
readonly list: Effect.Effect<ReadonlyArray<Item>>;
}
}
Step 2: Declare the Service Class
Empty class body — no make:, no static readonly layer. The interface and service class live in the same namespace.
import { Context } from 'effect';
import type { Effect } from 'effect';
export namespace MyModule {
export interface Interface {
readonly get: (id: string) => Effect.Effect<Item, MyModuleError>;
readonly list: Effect.Effect<ReadonlyArray<Item>>;
}
export class Service extends Context.Service<Service, Interface>()(
'@app/MyModule'
) {}
}
Step 3: Build the Raw Layer
Construct the service inside Layer.effect, capturing dependencies via yield*. Use Effect.fn for traced methods.
import { Effect, Layer, Context } from 'effect';
export namespace MyModule {
export interface Interface {
readonly get: (id: string) => Effect.Effect<Item, MyModuleError>;
readonly list: Effect.Effect<ReadonlyArray<Item>>;
}
export class Service extends Context.Service<Service, Interface>()(
'@app/MyModule'
) {}
export const layer = Layer.effect(
Service,
Effect.gen(function* () {
const config = yield* Config.Service;
const db = yield* Database.Service;
const get = Effect.fn('MyModule.get')(function* (id: string) {
const cfg = yield* config.get();
return yield* db.findById(cfg.table, id);
});
const list = Effect.fn('MyModule.list')(function* () {
const cfg = yield* config.get();
return yield* db.listAll(cfg.table);
});
return Service.of({ get, list });
})
);
}
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 7d ago First seen · 363 lines · 52 tokens per session scan A 31b05f537797
effect-incremental-migration is a skill published in the GitHub repository mpsuesser/pi-effect-harness (24 stars, last pushed 2mo ago), licensed MIT. It adds 52 tokens to every session and 2,878 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
effect-patterns-making-http-requests
Effect-TS patterns for Making Http Requests. Use when working with making http requests in Effect-TS applications.
effect-patterns-streams-sinks
Effect-TS patterns for Streams Sinks. Use when working with streams sinks in Effect-TS applications.
effect-patterns-resource-management
Effect-TS patterns for Resource Management. Use when working with resource management in Effect-TS applications.
effect-patterns-scheduling-periodic-tasks
Effect-TS patterns for Scheduling Periodic Tasks. Use when working with scheduling periodic tasks in Effect-TS applications.
effect
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.
effect-patterns-concurrency
Effect-TS patterns for Concurrency. Use when working with concurrency in Effect-TS applications.