CorvidLabs 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:
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.