liberal-accept-strict-return

Design TypeScript function signatures with broad input types and narrow return types.

Updated Sep 5, 2026
One-click install
npx skills add https://github.com/pohlai88/afenda-xforge-v5 --skill liberal-accept-strict-return-pohlai88
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: liberal-accept-strict-return
Source: https://github.com/pohlai88/afenda-xforge-v5/tree/main/.agents/skills/liberal-accept-strict-return
Command: npx skills add https://github.com/pohlai88/afenda-xforge-v5 --skill liberal-accept-strict-return-pohlai88

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Functions that return overly broad types force every caller to add null checks, type narrowing, and defensive code. This Skill applies Postel's Law to TypeScript API design so functions accept flexible inputs but return precise, immediately usable outputs. ## Core Features & Use Cases - Signature Design Guidance: Rules for making parameters liberal (optional fields, union types, multiple formats) while keeping return types strict (required fields, single canonical format). - Detection Patterns: Identifies the "too broad return" problem where callers must do extra work to consume a function's output. - Input/Output Type Separation: Patterns for distinct input and output interfaces, such as CreateUserInput versus User, with defaults applied to outputs. - Use Case: When building a reusable library function like viewportForBounds, accept bounds in multiple formats but return a Camera object with all required fields so callers can destructure results without undefined checks. ## Quick Start Ask the AI to review your TypeScript function signatures and refactor them to accept broad input types while returning strict, fully-populated output types.

Frequently Asked Questions about liberal-accept-strict-return

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

FAQPage Schema
How do I design TypeScript function signatures for reusable APIs?

Make parameter types broad with optional fields and union types so callers can pass data in multiple formats, and make return types strict with all required fields in a single canonical format. This follows Postel's Law: be liberal in what you accept and strict in what you produce.

What is Postel's Law in TypeScript type design?

Postel's Law applied to TypeScript means functions accept flexible input types but return precise output types. Inputs may have optional fields and union formats, while outputs have required fields and one canonical structure so consumers can use results directly.

Should input and output types be the same interface?

No, use separate types when input and output needs differ. An input type like CreateUserInput can have optional fields, while the output User type has all fields required with defaults applied, plus system-added fields like id and createdAt.

Why do callers get 'possibly undefined' errors on my function's return value?

This happens when the return type is as broad as the input type, with optional or union fields. Fix it by returning a stricter type where all fields are required, so callers can destructure and use the result without null checks.

When should I avoid union types in TypeScript return values?

Avoid union return types when a single canonical format would suffice, since unions force callers to narrow the type before use. Reserve unions for input parameters where accepting multiple formats genuinely helps callers.