Specification Pattern

Encapsulate TypeScript business rules as composable specification objects with AND, OR, and NOT operators.

Updated Mar 27, 2026

Search Tags:#typescript #validation #domain-driven design #specification pattern #reusable predicates #composable filters #prisma query translation

Ready to run

npx skills add https://github.com/quanngynx/GDGO-2026.Servexa-Warranty-AI --skill specification-pattern-quanngynx

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: Specification Pattern
Source: https://github.com/quanngynx/GDGO-2026.Servexa-Warranty-AI/tree/main/servexa-warranty-ai/.agents/skills/specification-pattern
Command: npx skills add https://github.com/quanngynx/GDGO-2026.Servexa-Warranty-AI --skill specification-pattern-quanngynx

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill helps you avoid scattered conditional logic by encapsulating business rules as composable, reusable objects you can apply consistently across filtering, validation, and query construction.

Core Features & Use Cases

Composable rules with AND/OR/NOT: Build complex predicates by combining smaller specifications instead of writing nested if statements.
TypeScript-first implementation: Uses generics, immutable constructor params, and strict-mode friendly design to keep specs safe and maintainable.
Supports domain-driven filtering and validation: Apply specifications to arrays in-memory for deterministic checks and to domain entities for invariant enforcement.
Optional query translation guidance: Lets the same specification concepts be extended to drive Prisma-style where clauses for efficient database querying.

Quick Start

Use the Specification Pattern to create small atomic TypeScript specs for each business rule, then compose them with .and(), .or(), and .not() to build a single rule applied via filter() or repository queries.

Frequently Asked Questions about Specification Pattern

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

FAQPage Schema

How do I encapsulate business rules as reusable predicates in TypeScript?▼

To encapsulate business rules as reusable predicates in TypeScript, create atomic specification objects implementing a generic interface with `isSatisfiedBy`, then compose them using `.and()`, `.or()`, and `.not()` operators to eliminate scattered conditional logic.

What is the specification pattern in domain-driven design?▼

The specification pattern in domain-driven design is a technique that encapsulates business rules as composable, reusable objects. It allows you to apply consistent logic across domain-driven filtering, entity validation, and query predicate construction instead of writing nested if statements.

Can I translate composable filters into Prisma where clauses?▼

Yes, you can translate composable filters into Prisma where clauses. The Skill provides optional query translation guidance, allowing the same specification concepts used for in-memory filtering to be extended to drive Prisma-style database queries efficiently.

How do I validate domain entities without scattered conditional logic?▼

You validate domain entities without scattered conditional logic by applying composable specification objects via the `isSatisfiedBy` method. This enforces domain invariants deterministically by checking small atomic business rules combined with AND, OR, and NOT operators.

Does TypeScript strict mode work with immutable specification objects?▼

Yes, TypeScript strict mode works seamlessly with immutable specification objects. The Skill uses a TypeScript-first implementation with generics, immutable constructor parameters, and strict-mode friendly design to keep composable business rules safe and maintainable.

When should I avoid using composable specifications for filtering?▼

You should avoid using composable specifications for simple, one-off filtering tasks where introducing a generic Specification interface would add unnecessary abstraction overhead, making the code harder to read than straightforward inline conditional logic.