Safe Public Release

Safe Public Release

Turn a private, vendor-provided, runtime-generated, or mixed artifact into a public package without leaking secrets, private state, or material that cannot be redistributed.

One pipeline:

intent → owner issue tree → inventory → provenance → license → security/privacy → allowlist → clean package → approval → publish → fresh public verification → maintenance

The skill is allowlist-first. Never copy a whole runtime/private directory and hope denylist cleanup finds everything.

Hard safety boundary

Publishing is an outward mutation. Before creating a public repository, changing visibility, pushing a release, or publishing to a registry:

1. complete the inventory and release manifest;
2. reach PACKAGE-READY with no unresolved provenance/license/security blockers;
3. show the user the release dry run;
4. receive explicit approval for the named public target and artifact set.

A request to "prepare" or "review" a release authorizes read-only analysis and private/internal artifacts, not public publication.

What this skill is for

• public agent skills or plugin bundles;
• prompts, templates, playbooks, starter kits, examples;
• reusable source extracted from a private project;
• workshop/course assets selected for public release;
• benchmark fixtures or datasets;
• demo repos derived from production/private work;
• vendor/runtime exports with uncertain provenance;
• moving an existing private repo or selected subtree to a public repo.

What this skill is NOT for

• Upstream bugfix PR: use the repository's contribution/PR workflow and regression tests.
• Security vulnerability disclosure: use the vendor's private security route.
• Tool/product evaluation: route to the product/runtime owner; evaluation does not grant redistribution rights.
• Creating a private corp- department:* use corp-new; it requires a separate approval dry run.
• Simple public edit: when the source is already public, owner-authored, clearly licensed, and contains no mixed private/runtime state, use the normal repository workflow.

Setup

Resolve configuration from the user, project instructions, then defaults:

## Safe Public Release Config

- internal_owner_repo: owner/corp-opensource-or-project
- public_github_owner: owner
- staging_root: /tmp/safe-public-release
- allowed_public_licenses: MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause
- secret_scanners: gitleaks, trufflehog
- approval_mode: explicit-before-publish

Do not block preparation when optional scanners are unavailable. Record the limitation and keep the release blocked until equivalent manual and repository-native checks are completed. Never claim a scan ran when it did not.

Owner issue tree

Before extraction or packaging, find or create three scopes in the internal owner repo:

1. Owner epic — intended release, audience, source, risk owner, definition of done.
2. Inventory/review child — provenance, licenses, companion files, security classification, allowlist.
3. Publish/verify child — public repo/package creation after approval, fresh-clone verification, maintenance.

Separate unrelated work:

• product/tool smoke → product/runtime owner;
• runner or CI provisioning → infrastructure owner;
• launch content/distribution → media/community owner;
• commercial negotiation → sales/CRM owner.

If the user has an issue-management skill such as manager, use it for the issue tree and cross-repo links.

Status model

Use exactly one current status:

Progress states

• DISCOVERED
• INVENTORY
• PROVENANCE-CLEARED
• LICENSE-CLEARED
• SECURITY-CLEARED
• PACKAGE-READY
• APPROVED
• PUBLISHED
• VERIFIED
• MAINTAINED

Block states

• BLOCKED-PROVENANCE
• BLOCKED-LICENSE
• BLOCKED-SECURITY
• BLOCKED-OWNER-APPROVAL
• NO-GO-VENDOR-PROTECTED
• NO-GO-MIXED-PRIVATE-DATA

Every blocked status needs one concrete unblock_event: source found, written permission, license clarified, secret removed and rotated, scope reduced, or owner approval.

Step 1 — Capture the release intent

Record:

• intended public artifact/repository;
• target audience and use case;
• source environments/repositories/providers;
• expected bundles;
• intended public license;
• owner who can approve publication;
• maintenance owner after publication.

Do not create the public repository yet.

Step 2 — Inventory before copying

Create release-manifest.yaml using the bundled template.

For each candidate artifact record:

• stable artifact ID;
• source provider/owner;
• source version, tag, commit, or product version;
• source locator in an internal note; public manifest must not contain private absolute paths or internal URLs;
• original license/terms;
• redistribution basis;
• whether it was modified and how;
• complete companion-file bundle;
• exclusions and reason;
• current decision.

Visibility inside an application or runtime does not prove ownership or permission to redistribute.

Step 3 — Classify every file

Every file in the future public tree must be reachable from an explicit allowlist entry.

Step 4 — Provenance gate

For each candidate prove:

• who authored/owns it;
• which exact version is being released;
• where companion files come from;
• what modifications were made;
• which public license will apply;
• why redistribution is permitted.

Unknown provenance → BLOCKED-PROVENANCE.

Do not publish a "cleaned up" artifact whose origin cannot be explained.

Step 5 — License gate

Check:

• root and per-file licenses/notices;
• dependency and embedded asset licenses;
• generated-output terms;
• trademark/name restrictions;
• copyleft/share-alike obligations;
• redistribution/extraction restrictions;
• compatibility between source license and intended public license.

Attribution is not permission. A missing, custom, or unclear license means BLOCKED-LICENSE until the artifact is excluded or permission is obtained.

The skill does not provide legal advice. When license interpretation changes material risk, record the evidence and route the decision to the appropriate owner or counsel.