/safe-public-release

name: safe-public-release
description: >-
  Use when publishing, open-sourcing, exporting, sanitizing, or moving code,
  agent skills, prompts, templates, fixtures, datasets, workshop assets, or
  other artifacts from a private repository, vendor/runtime environment, or
  mixed working directory into a public repository or registry. Builds a
  provenance inventory, license/security review, explicit allowlist, clean
  staging package, approval dry run, and fresh public clone/install smoke.
  Triggers on "open source this", "publish these skills", "make this repo
  public", "export and sanitize", "подготовь публичный релиз", "выложи
  скиллы", "опенсорсни", "санитизируй и опубликуй". NOT for ordinary
  upstream bugfix PRs, vulnerability disclosure, or creating a corp-* department.

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](references/release-manifest.example.yaml).

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

| Class | Default decision | |---|---| | Owner-authored source | Candidate after license/security review | | Third