boundary-discipline

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

1|Updated Feb 2, 2026
One-click install
npx skills add https://github.com/rockcookies/skills --skill boundary-discipline-rockcookies
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: boundary-discipline
Source: https://github.com/rockcookies/skills/tree/main/skills/cursor-plugins/boundary-discipline
Command: npx skills add https://github.com/rockcookies/skills --skill boundary-discipline-rockcookies

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Scattered validation and redundant nil checks make code noisy, hard to test, and give a false sense of safety. This Skill guides you to place validation, type narrowing, and error handling only at system boundaries so internal code stays clean and business logic remains testable without frameworks. ## Core Features & Use Cases - Boundary Validation: Validate CLI args, config files, network payloads, and external API responses at the edge, then trust typed data everywhere inside. - Pure Business Logic: Keep parsing, prompt construction, scoring, and assessment as pure functions with no framework dependencies. - 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, parse and validate the request body into domain types at the handler, then call pure functions that operate on trusted typed state. ## Quick Start Ask the AI to review your validation and error handling placement using the boundary-discipline principles when wiring a new framework adapter.

Frequently Asked Questions about 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 only at system boundaries: CLI arguments, config files, network protocols, and external APIs. Once data crosses the boundary as typed domain objects, trust it unconditionally and avoid re-validation deeper in the call chain.

How to keep business logic testable without a framework?▼

Write business logic as 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, so tests need no framework setup.

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

No. If the boundary already validated the data, redundant nil checks inside the system are noise and give a false sense of safety. Trust the types once data has crossed the boundary.

When should I not apply boundary-only validation?▼

The pattern assumes a clear boundary exists where raw input enters the system. If data arrives from untrusted internal sources or the boundary itself cannot fully validate, additional defensive checks inside may still be warranted.

What types should my 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.