principle-boundary-discipline

Concentrate validation and error handling at system boundaries while keeping business logic in pure functions.

1|Updated Jul 5, 2026
One-click install
npx skills add https://github.com/yersonargotev/packy --skill principle-boundary-discipline-yersonargotev
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: principle-boundary-discipline
Source: https://github.com/yersonargotev/packy/tree/main/bundle/skills/principle-boundary-discipline
Command: npx skills add https://github.com/yersonargotev/packy --skill principle-boundary-discipline-yersonargotev

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Scattered validation and framework-coupled business logic make code noisy, redundant, and hard to test. This Skill guides you to validate data once at system boundaries and keep internal logic pure and framework-free. ## Core Features & Use Cases - Boundary Validation: Place validation, type narrowing, and error handling at CLI args, config files, network protocols, and external APIs. - Pure Business Logic: Keep parsing, prompt construction, and scoring as pure functions with no framework dependencies, so they can be tested without the framework. - Clean Public Surfaces: Avoid re-exporting transport, storage, or wire types through your public API; expose domain concepts instead. - Use Case: When wiring a new CLI command or API adapter, apply this Skill to decide exactly where validation belongs and which functions should be pure transforms. ## Quick Start Ask the AI to review your validation and error handling placement using the boundary discipline principle when wiring a new CLI command or framework adapter.

Frequently Asked Questions about principle-boundary-discipline

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

FAQPage Schema
Where should input validation go in an application?▼

Input validation belongs at system boundaries: CLI argument parsing, config file loading, network handlers, and external API calls. Validate once at the boundary, parse raw data into domain types, then trust those types throughout internal code without re-checking.

How do I make business logic testable without a framework?▼

Keep business logic in pure functions with no framework dependencies: parse functions transform raw bytes to typed state, and scoring functions transform state to results. The framework shell becomes a thin mechanical layer that just calls these functions.

Should internal functions re-validate data already checked at the boundary?▼

No. If the boundary already validated and narrowed the data into typed domain objects, redundant nil checks deep in call chains add noise and a false sense of safety. Trust the types inside the system.

When should I not apply boundary-only validation?▼

Boundary discipline assumes a clear trust perimeter. If data crosses trust boundaries mid-flow, such as calling an untrusted external service from deep inside the system, that call site becomes a new boundary and needs its own defensive handling.