Implement, debug, refactor, migrate, review, or explain Effect TypeScript code. Use when a task touches `effect` or `@effect/*` APIs, especially services, layers, schemas, runtime wiring, platform or CLI packages, Effect testing, or Promise-to-Effect migration.
98
100%
Does it follow best practices?
Impact
93%
1.16xAverage score across 3 eval scenarios
Passed
No known issues
{
"context": "The agent is asked to implement a NotificationService in Effect TypeScript. This scenario tests whether the agent writes idiomatic Effect code: using proper service definition patterns, keeping runtime execution at boundaries, modeling errors with tagged types, and structuring the layer graph correctly.",
"type": "weighted_checklist",
"checklist": [
{
"name": "Context.Tag usage",
"description": "The service is defined using Context.Tag with a unique string identifier (e.g., @app/NotificationService or similar namespace pattern)",
"max_score": 8
},
{
"name": "Readonly methods",
"description": "All service interface methods are declared as readonly",
"max_score": 5
},
{
"name": "Effect.fn for service method",
"description": "The send method (and any internal helpers) uses Effect.fn('Name') rather than plain arrow functions returning Effect",
"max_score": 8
},
{
"name": "Tagged error types",
"description": "EmailDeliveryError and PushDeliveryError (or equivalent names) are defined as tagged errors using Schema.TaggedError or Data.TaggedError, not as string errors or plain Error subclasses",
"max_score": 8
},
{
"name": "Domain model variants",
"description": "Notification variants (email vs push) are modeled as a discriminated union, preferably using Schema.TaggedClass or Schema.Union",
"max_score": 7
},
{
"name": "Layer graph for dependencies",
"description": "EmailClient and PushClient dependencies are injected via the layer system (Layer.effect, Layer.succeed, or similar) rather than passed as constructor arguments or hidden globals",
"max_score": 10
},
{
"name": "No runPromise in service",
"description": "No call to Effect.runPromise, Effect.runSync, or any Effect.run* variant appears inside the service or error modules",
"max_score": 10
},
{
"name": "No globals",
"description": "No module-level mutable state, singleton instances, or imported globals are used to hold dependencies",
"max_score": 8
},
{
"name": "Test layer provided",
"description": "A testLayer or test double (using Layer.succeed) is provided for NotificationService or its dependencies, making it easy to test without real infrastructure",
"max_score": 8
},
{
"name": "send method environment",
"description": "The send method's Effect return type does not expose extra environment requirements in its R channel beyond what the live layer satisfies",
"max_score": 8
},
{
"name": "No Promise returns in service",
"description": "Service methods do not return Promise values; they return Effect values",
"max_score": 8
},
{
"name": "Error channel specificity",
"description": "The error channel in the send method's return type uses specific tagged error types rather than string, unknown, or Error",
"max_score": 7
},
{
"name": "Barrel export correctness",
"description": "The index.ts barrel file exports the service tag, live layer, error types, and models cleanly without re-exporting implementation internals",
"max_score": 5
}
]
}