skill-private-public-repo-governance

Separates private development repositories from curated public mirrors with allowlist-based publication.

Updated Apr 9, 2026
One-click install
npx skills add https://github.com/longdang193/project-OS-starter --skill skill-private-public-repo-governance-longdang193
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: skill-private-public-repo-governance
Source: https://github.com/longdang193/project-OS-starter/tree/main/generated_agents/claude/skills/skill-private-public-repo-governance
Command: npx skills add https://github.com/longdang193/project-OS-starter --skill skill-private-public-repo-governance-longdang193

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Teams maintaining both a private engineering repo and a public product-facing repo risk leaking internal plans, agent assets, and workflow docs into public releases, or drifting between two sources of truth. ## Core Features & Use Cases - Repo Role Model: Defines the private repo as the development source of truth and the public repo as a curated downstream mirror. - Content Classification: Sorts paths into always_private, usually_public, and review_before_publish buckets with keep, sanitize, or omit treatments. - Boundary Validation: Provides a pre-publish checklist that blocks leaks of .agents/, .cursor/, internal docs, and private-path references. - Use Case: Before pushing a new release to your public GitHub mirror, run the boundary validation pass to confirm no internal planning docs or agent folders slipped into the export. ## Quick Start Use the private/public repo governance skill to classify my repository contents and validate the export before publishing to the public mirror.

Frequently Asked Questions about skill-private-public-repo-governance

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

FAQPage Schema
How do I publish from a private repo to a public repo safely?▼

Develop only in the private repo, then build a curated export using an allowlist of approved paths rather than copying everything and deleting. Validate the export boundary for leaked internal content before pushing to the public mirror.

What files should stay private when mirroring a repository publicly?▼

Keep agent and rule folders like `.agents/` and `.cursor/`, internal planning docs, logs, scratch files, and starter adoption guides private. Publish stable source code, README, product-facing docs, setup guides, and reviewed examples.

Should I delete a whole file if it contains one private field?▼

No. Classify sensitivity at the file, section, and field level, then sanitize private payloads while preserving safe structure. Redact values, not evidence, so the public mirror keeps navigational shape and reproducibility.

When should I not use a private/public mirror workflow?▼

Avoid this approach for normal single-repo branching strategies, runtime or product validation, and deployment engineering unrelated to repo boundaries. It is designed specifically for publication-boundary management between two repositories.

Why does my public repo look like a workbench instead of a product repo?▼

This happens when teams develop directly in the public repo or treat it as the private repo minus a few deletions. Fix it by keeping all development private and publishing outward through an intentional, validated curated export.