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:

```markdown
## 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-party redistributable source | Candidate with preserved notices |
| Generated build artifact | Regenerate from allowlisted source |
| Runtime state, cache, queue, session | Exclude |
| Logs, transcripts, histories | Exclude or separate privacy review |
| Credentials, tokens, cookies, keys | Exclude; rotate if exposed |
| Customer, student, employee, user data | Exclude; aggregate only under a separate privacy owner |
| Vendor-protected or unknown source | Block |
| Mixed bundle | Split before review |
| Symlink, submodule, archive, binary | Inspect target/content and license before allowlist |

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