# Public Release Audit

> Audit a private repository for safe public release without changing visibility prematurely.

- Skill: `corvidlabs/public-release-audit` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add corvidlabs/public-release-audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/corvidlabs/public-release-audit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: CorvidLabs (https://skillmd.com/u/corvidlabs)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/corvidlabs/public-release-audit

---


# Public Release Audit

Use this skill before making a private repository public or creating its first public
release.

## Audit the repository

Check the current tree and relevant history for:

- credentials, tokens, private endpoints, and secret-bearing configuration
- personal paths, local machine assumptions, internal data, and sensitive fixtures
- portable fixtures and CI that run without private local dependencies
- accurate README, examples, license, contributing guidance, and security reporting
- public-safe issue templates, release notes, package metadata, and documentation

Prefer repository-relative discovery and secret scanning when available:

```sh
git ls-files
fledge run --list
fledge lanes list
# When the project defines them, e.g.:
fledge lanes run verify
fledge lanes run audit
```

Scan the **tree and full git history that will become public**. When gitleaks is available,
prefer both a tree scan and a history scan (this catalog uses `gitleaks dir` and
`gitleaks git`); otherwise use the repository's documented secrets task. Do not use
federated Let discovery as part of a public-safety audit of content to publish—Let can
surface private local agent metadata that is not in the repository.

Run portability and CI checks with repository-relative fixtures. Record findings and
remediations in the PR or release checklist.

## Make the decision explicit

Do not change repository visibility as part of the audit. Complete the audit, present
the remaining risks, and obtain an explicit owner decision to make the repository
public. If the live testbed contains internal context or experimental behavior, publish
a sanitized demo or template instead of the working sandbox.