principle-boundary-discipline

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

4|1|Updated Dec 16, 2023
One-click install
npx skills add https://github.com/Shtian/AuthentiClash --skill principle-boundary-discipline-shtian
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: principle-boundary-discipline
Source: https://github.com/Shtian/AuthentiClash/tree/main/.claude/skills/principle-boundary-discipline
Command: npx skills add https://github.com/Shtian/AuthentiClash --skill principle-boundary-discipline-shtian

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Scattered validation and framework-coupled business logic make codebases noisy, redundant, and hard to test. This Skill guides you to place guards only where data crosses system boundaries and to keep internal code clean and trustworthy. ## Core Features & Use Cases - Boundary Validation: Validate CLI arguments, config files, network payloads, and external API responses at parse time, not deep in call chains. - Pure Business Logic: Extract scoring, parsing, and prompt construction into 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 HTTP endpoint or CLI command, apply this Skill to decide exactly where validation belongs and which logic should be extracted into testable pure functions. ## Quick Start Review my new API handler and tell me where validation should live and which logic should become pure functions.

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 live in an application?▼

Input validation belongs at system boundaries: CLI argument parsing, config file loading, network handlers, and external API clients. Once data crosses the boundary as typed domain values, internal code should trust the types and avoid redundant checks.

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

Extract business logic into pure functions with no framework dependencies: parse functions transform raw bytes into typed state, and scoring functions transform state into results. The framework shell then just calls these functions mechanically.

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

No. If the boundary already validated and narrowed the data into typed domain values, re-validation deep in call chains is redundant noise. Propagate errors and trust the types inside the system.

When should I not apply boundary-only validation?▼

Avoid it when data crosses a trust boundary mid-flow, such as calling an untrusted third-party service from deep inside the system. Any point where untrusted data enters is a boundary and needs defensive handling.

What types should a public API expose?▼

Expose domain concepts, not the boundary's private representation. Do not re-export transport, storage, framework, or wire types through the public surface; keep general-purpose mechanism inside and special-purpose policy at the edge.