principle-boundary-discipline

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

136|8|Updated May 9, 2026
One-click install
npx skills add https://github.com/Sma1lboy/rove --skill principle-boundary-discipline-sma1lboy
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: principle-boundary-discipline
Source: https://github.com/Sma1lboy/rove/tree/main/.agents/skills/pstack/skills/principle-boundary-discipline
Command: npx skills add https://github.com/Sma1lboy/rove --skill principle-boundary-discipline-sma1lboy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Scattered validation and defensive checks throughout a codebase create noise, redundancy, and a false sense of safety, while business logic tangled in framework wiring becomes untestable. This Skill guides you to place validation, type narrowing, and error handling exactly where data crosses system boundaries. ## Core Features & Use Cases - Boundary Validation: Validate CLI arguments, config files, network payloads, and external API responses once at the entry point, then trust typed data internally. - Pure Business Logic: Keep parsing, prompt construction, scoring, and assessment 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 framework adapter, apply this Skill to decide where validation belongs and which logic should be extracted into pure functions. ## 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 API 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 clients. Validate once at the entry point, parse raw data into domain types, then trust those types throughout internal code.

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

Extract business logic into pure functions with no framework dependencies, such as parse functions transforming raw bytes to typed state or scoring functions mapping state to results. The framework shell then just calls these functions mechanically.

Should I add nil checks deep in my call chain?▼

No, redundant nil checks deep in call chains are unnecessary if the boundary already validated the data. Once data crosses the boundary as a typed value, internal code should trust the types and propagate errors rather than re-validate.

When should I not apply boundary-only validation?▼

Boundary-only validation fits systems with clear entry points and typed internal flows. It is less suitable when data enters through many untracked paths or when internal components are consumed by untrusted third parties who bypass your boundaries.