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
A junior developer has started a new Effect TypeScript project, but the configuration has several problems. Your job is to audit the project and produce a corrected configuration.
The project files are at /workspace/scenario-2-project/. The relevant files are:
package.json — lists dependencies and scriptstsconfig.json — TypeScript compiler configuration.vscode/settings.json — VS Code workspace settings (may or may not exist)src/index.ts — application entrypoint (for reference)package.json to /workspace/scenario-2-project/package.json (keep all existing app dependencies; only fix Effect-related packages and scripts)tsconfig.json to /workspace/scenario-2-project/tsconfig.json/workspace/scenario-2-project/.vscode/settings.json with the recommended TypeScript settings for this kind of project/workspace/scenario-2-project/AUDIT.md explaining each problem found and what was changedThe current package.json includes:
@effect/schema as a direct dependency@effect/platform-node and @effect/platform-bun installedThe current tsconfig.json has:
"strict": falseexactOptionalPropertyTypesverbatimModuleSyntax@effect/language-service pluginFix all issues you find by applying standard Effect project conventions. The project targets the Node.js runtime.