fusionaly-boundaries

Enforce OSS and Pro separation with public API extension patterns.

10|2|Updated Dec 17, 2025
One-click install
npx skills add https://github.com/karloscodes/fusionaly-oss --skill fusionaly-boundaries
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: fusionaly-boundaries
Source: https://github.com/karloscodes/fusionaly-oss/tree/main/.claude/skills/fusionaly-boundaries
Command: npx skills add https://github.com/karloscodes/fusionaly-oss --skill fusionaly-boundaries

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Keeps Fusionaly OSS and Fusionaly Pro separate, preventing Pro features or license changes from leaking into OSS and vice versa.

Core Features & Use Cases

  • Defines strict OSS/Pro separation and governance rules.
  • Guides safe extension: Pro extensions use public APIs and OSS remains unchanged.
  • Provides clear extension patterns and auditing practices to prevent cross-repo contamination.

Quick Start

Audit your repository against the Fusionaly Boundaries guidelines to ensure OSS remains standalone and Pro features interact only through public APIs.

Frequently Asked Questions about fusionaly-boundaries

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

FAQPage Schema
How do I enforce boundaries between open source and pro repository code?

To enforce boundaries between open source and pro repository code, apply strict governance rules where the OSS codebase remains unmodified while Pro extensions interact exclusively through public APIs to prevent cross-repo cross-contamination.

What is OSS and Pro cross-contamination in repository governance?

OSS and Pro cross-contamination in repository governance occurs when Pro features or license changes leak into the open source codebase or vice versa, which is prevented by keeping the repositories strictly separate.

How do I extend Pro features without modifying the core OSS code?

You can extend Pro features without modifying the core OSS code by using clearly defined extension patterns that require Pro extensions to interact with the base repository only through its public APIs.

Can I audit my repository for clean separation between OSS and Pro tiers?

Yes, you can audit your repository against strict separation guidelines to ensure the OSS tier remains standalone and that Pro features interact only through public APIs without altering the base code.

When do I need strict separation rules for open source and commercial tiers?

You need strict separation rules for open source and commercial tiers when managing repository governance workflows where the OSS code must remain standalone and unmodified while commercial extensions rely on public APIs.