engineering

Enforces TypeScript and Effect coding rules for architecture, schema design, testing, and review.

1|Updated Jan 29, 2026
One-click install
npx skills add https://github.com/MP281X/deslop --skill engineering-mp281x
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: engineering
Source: https://github.com/MP281X/deslop/tree/main/tools/workflow/src/agents/skills/engineering
Command: npx skills add https://github.com/MP281X/deslop --skill engineering-mp281x

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Codebases drift into inconsistent patterns: redundant type annotations, hand-rolled wrappers over library primitives, leaked error types, and tests that assert nothing. This Skill gives an AI a concrete rulebook of good and bad TypeScript/Effect patterns so generated and reviewed code follows one consistent engineering standard. ## Core Features & Use Cases - Type and Schema Rules: Enforces inferred types, satisfies over assertions, Schema.Struct over Schema.Class, and schema-owned validation via .make. - Effect Patterns: Standardizes Effect.fn for functions with arguments, standalone pipe, Context.Service with static layers, Schema.TaggedError with preserved causes, and Effect.acquireRelease for resource lifetimes. - Code Quality Gates: Bans native globals (Date, Math.random, process.env) in favor of Effect services, forbids wrapper functions and legacy compatibility code, and defines what meaningful tests look like. - Use Case: When implementing a new service in an Effect-based monorepo, apply this Skill so the generated code uses the correct service shape, error handling, and module layout on the first pass. ## Quick Start Use the engineering skill to review this TypeScript service implementation and rewrite any code that violates the Effect and Schema rules.

Frequently Asked Questions about engineering

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write Effect services with Context.Service correctly?

Define the service shape in a namespace, create the tag with Context.Service, and expose constructors as static layer methods like Layer.effect(this, makeImpl). Avoid readonly statics, default implementations, and identity wrappers like Service.of.

When should I use Schema.Struct instead of Schema.Class?

Use Schema.Struct paired with `type X = typeof X.Type` for plain data definitions. Schema.Class is discouraged in this rule set; the struct pattern keeps types and schemas co-located without class semantics.

Should I use Effect.fn or Effect.gen for new functions?

Use Effect.fn with a name whenever the function takes arguments, since it provides tracing and naming. Use plain Effect.gen only for argument-less compositions.

Why does this rule set ban try/catch and Effect.catch fallbacks?

Catching errors and returning empty data hides malformed input instead of surfacing it. The rules require fail-fast behavior with one domain error per service, created via Schema.TaggedError with the original cause preserved.

Can I use native globals like Date, Math.random, or process.env in Effect code?

No. Replace them with Effect capabilities: Clock for time, Random for randomness, Config for environment variables, and FileSystem for file access. This keeps effects testable and dependency-injected.

What makes a good test under these engineering rules?

Tests target only public service interfaces, share one composed layer via it.layer, and assert business-specified values rather than behavior libraries already guarantee. Avoid mocking modules; use layers as the substitution seam.