principle-boundary-discipline

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

Updated Mar 27, 2026
One-click install
npx skills add https://github.com/gmackie/agent-skills --skill principle-boundary-discipline-gmackie
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: principle-boundary-discipline
Source: https://github.com/gmackie/agent-skills/tree/main/skills/principle-boundary-discipline
Command: npx skills add https://github.com/gmackie/agent-skills --skill principle-boundary-discipline-gmackie

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Scattered validation and redundant nil checks create noisy code and a false sense of safety. This Skill guides you to validate data once at system boundaries (CLI args, config files, external APIs, network protocols) and trust typed data inside the system, so business logic stays testable without framework dependencies. ## Core Features & Use Cases - Boundary Validation Guidance: Directs validation, type narrowing, and defensive error handling to CLI, config, network, and external API entry points. - Pure Function Extraction: Helps move business logic into pure functions with no framework dependencies, such as parse transforms and prompt construction. - API Surface Discipline: Prevents leaking transport, storage, or wire types through the public surface of a module. - Use Case: When wiring a new framework adapter or CLI command, apply this Skill to decide exactly where config parsing and error handling belong, then extract the core logic into a pure function the thin shell simply calls. ## Quick Start Review my new CLI adapter code and move all validation to the argument parsing boundary while extracting the business logic into pure functions.

Frequently Asked Questions about principle-boundary-discipline

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

FAQPage Schema
How do I decide where to put validation in my application?▼

Place validation at system boundaries where data first enters: CLI argument parsing, config file loading, external API responses, and network protocols. Once data crosses the boundary as typed domain objects, internal code should trust the types and skip re-validation.

How to make business logic testable without a framework?▼

Extract business logic into pure functions with no framework dependencies, such as parse functions transforming raw bytes into typed state. The framework shell stays thin and mechanical, just calling these pure functions, so tests run without booting the framework.

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

No. Redundant nil checks deep in call chains are noise if the boundary already validated the data. Ask whether the data is crossing a system boundary right now; if not, the validation is redundant and should be removed.

Can I expose transport or wire types through my public API?▼

No. Do not re-export transport, storage, framework, or wire types through the public surface. Expose domain concepts instead, keeping general-purpose mechanism inside the system and special-purpose policy at the edge.

When does boundary discipline not apply?▼

Boundary discipline applies whenever data crosses a trust boundary. It is less relevant for small scripts with no external inputs, but any code consuming config, user input, or external APIs benefits from validating once at the edge.