Guides functional domain modeling in server-side TypeScript using discriminated unions, pure functions, Result types for domain models, use cases, repositories, state transitions, business logic.
npx claudepluginhub iwasa-kosui/functional-ts-principlesThis skill uses the workspace's default tool permissions.
Principles for writing domain models in server-side TypeScript. Instead of class-based OOP, this approach maximizes the TypeScript type system through a functional style.
boundary-defense.mddeclarative-style.mddomain-modeling.mderror-handling.mdexamples/sensitive-type-arktype.tsexamples/sensitive-type-valibot.tsexamples/sensitive-type.tsexamples/taxi-request-arktype.tsexamples/taxi-request-valibot.tsexamples/taxi-request.tsresult-libraries/byethrow.mdresult-libraries/fp-ts.mdresult-libraries/neverthrow.mdresult-libraries/option-t.mdstate-modeling.mdtest-data.mdvalidation-libraries/arktype.mdvalidation-libraries/valibot.mdvalidation-libraries/zod.mdGuides functional domain modeling in server-side TypeScript using Discriminated Unions for states, pure functions for transitions, Result types for errors, and defensive boundaries for domain models, use cases, repositories, and business logic.
Provides TypeScript functional patterns for ADTs, discriminated unions, Result/Option types, branded types. Use for state machines, type-safe domain models, and error handling.
Guides idiomatic TypeScript development with strict mode, interfaces vs types, discriminated unions, flat control flow, type guards, and Result patterns. Use for writing TS code, Node.js services, or React apps.
Share bugs, ideas, or general feedback.
Principles for writing domain models in server-side TypeScript. Instead of class-based OOP, this approach maximizes the TypeScript type system through a functional style.
Represent states with discriminated unions using kind as the unified discriminant. Use type (not interface), companion objects, branded types, Readonly<>, function property notation, and one-concept-per-file structure.
Validation library detection: Check dependencies / devDependencies in the project's package.json for branded type syntax:
zod → validation-libraries/zod.mdvalibot → validation-libraries/valibot.mdarktype → validation-libraries/arktype.mdDetails: domain-modeling.md
Express state transitions with pure functions. The argument type constrains valid source states, and the return type makes the target state explicit. Invalid transitions become compile errors. Use assertNever for exhaustiveness checking.
Details: state-modeling.md
Do not throw exceptions; treat errors as values using the Result type. Define error types as discriminated unions so callers can handle them exhaustively.
Library detection: Check dependencies / devDependencies in the project's package.json:
neverthrow → result-libraries/neverthrow.mdbyethrow → result-libraries/byethrow.mdfp-ts → result-libraries/fp-ts.mdoption-t → result-libraries/option-t.mdDetails: error-handling.md
Validate external inputs (API requests, DB results, file reads) with validation library schemas at runtime. Trust types inside the domain layer. Do not use type assertions (as). Apply Sensitive<T> wrapper to PII fields.
Details: boundary-defense.md
Write array transformations declaratively using filter / map / reduce with companion object predicates. Model domain events as immutable records.
Details: declarative-style.md
Define test data with as const satisfies Type to preserve discriminant literal types and prevent widening.
Details: test-data.md
These are recommendations, not strict rules. You may use your judgment based on context, but if you deviate from a principle, explicitly state the reason in a comment.
Typical justified reasons to deviate: