system-boundaries

Centralize external API, shell, and filesystem calls through service modules.

5|Updated Apr 1, 2026
One-click install
npx skills add https://github.com/TechyMT/claude-code-superpowers --skill system-boundaries
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: system-boundaries
Source: https://github.com/TechyMT/claude-code-superpowers/tree/main/skills/system-boundaries
Command: npx skills add https://github.com/TechyMT/claude-code-superpowers --skill system-boundaries

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Clarifies the inside/outside line of a codebase by preventing ad-hoc direct calls to external systems (LLM APIs, MCP servers, shell, filesystem, Git) and centralizing error handling, retries, and permission checks so tools remain safe and predictable.

Core Features & Use Cases

  • Central boundary modules: route Claude API and other external calls through services/api and services/mcp so retry, streaming, and token budget logic live in one place.
  • Sandboxed file and shell access: enforce path resolution with getResolvedPath, use execFile wrappers to avoid shell interpolation, and gate operations with the permission system.
  • Git helpers and graceful failures: use utils/git.ts wrappers to handle "not a git repo" cases and non-zero exits consistently.
  • Use case: Adding a new external integration—build a services/[name] module to encapsulate network errors, rate limits, auth, and retries instead of sprinkling fetch() or exec() calls across tools.

Quick Start

Route all external API, filesystem, and shell calls through a dedicated services module, enforce execFile argument arrays, and resolve paths via the sandboxing helper before allowing tool use.

Frequently Asked Questions about system-boundaries

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

FAQPage Schema
How do I centralize external API calls and prevent ad-hoc shell commands in my codebase?

Prevent direct shell calls by enforcing execFile argument arrays instead of string interpolation, routing access through dedicated service modules, and gating operations with a permission system to keep tool execution safe and predictable.

What is the best way to handle API rate limits and retries for LLM integrations?

The best way to handle API rate limits is to route external calls through a centralized services module where retry logic, streaming, and token budget management live in one place, preventing scattered fetch calls.

How do I sandbox filesystem access and resolve paths safely for tools?

Sandbox filesystem access by enforcing path resolution with a dedicated helper before allowing tool use, ensuring tools avoid direct unauthorized file access and operations remain within designated boundaries.

How do I handle "not a git repo" errors and non-zero exits consistently?

Handle "not a git repo" errors and non-zero exits consistently by using dedicated Git wrapper utilities that encapsulate shell interactions and standardize failure states instead of executing raw Git commands.

Does this approach work for centralizing MCP server interactions and token budgets?

Yes, this approach works for MCP server interactions by routing them through dedicated services modules where retry, streaming, and token budget logic are centralized, preventing unpredictable ad-hoc calls to external systems.