public-source-release-audit
Skill20 starsChanged 2 months agoMITView on GitHub
Check a Git repository's current candidate for high-confidence credential, private-key, and machine-home leaks, then perform a bounded public-release review. Use before publishing source or opening a public PR; do not use it to claim complete history or workflow-execution safety.
In this repository16 other files it gives its agents.
- AGENTS.mdAGENTS.md
- code-reviewSkill
- gemini-files-apiSkill
- harness-engineeringSkill
- hint-overlay-visual-verificationSkill
- ios-xcodegenSkill
- lifecycle-and-side-effects-correctnessSkill
- local-model-servingSkill
- mechanism-auditSkill
- meeting-transcriptionSkill
- silent-pushes-setupSkill
- spec-creation-updatingSkill
- swift-testingSkill
- swiftui-view-refactorSkill
- xcode-buildSkill
- xcode-cloudSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
Use this skill to answer a narrow question honestly: does the current source candidate contain a supported high-confidence leak, and have …
- Distinctive: line 14
Run the repository's own verifier when it exists.
- Distinctive: line 102
Do not summarize the bounded verdict as “the repository is safe.” Full-history investigation is a separate, exceptional workflow using …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Public-Source Release Audit
Use this skill to answer a narrow question honestly: does the current source candidate contain a supported high-confidence leak, and have the separate human and GitHub-native release checks been confirmed?
Automated Current-Source Check
Run the repository's own verifier when it exists. Then run:
ruby <skill-directory>/scripts/check_current_source.rb <repository>The checker reads exact Git-index blobs so an unstaged replacement cannot hide the candidate. It also scans tracked and non-ignored untracked worktree files for early feedback. It reports only paths and finding categories, never the matched content.
The supported lexical forms are deliberately small:
- PEM, OpenSSH, PGP, and PuTTY private-key headers;
- GitHub
ghp_,gho_,ghu_,ghs_,ghr_, andgithub_pat_token prefixes; - AWS
AKIA/ASIAaccess-key IDs and canonical named 40-character secret access-key values; - OpenAI
sk-andsk-proj-key prefixes; - explicit
Authorization: Bearerheader or map values; and - literal, commonly source-escaped, or
file://-wrapped rooted POSIX familiesUsers/<name>,var/root,private/var/root,home/<name>, androot, plus drive-letterUsers\\<name>paths, including UTF-8 profile names and bounded environment and command-option values.
The home-path rule covers literal paths and common source escaping for POSIX slashes and Windows backslashes. It does not decode URL-encoded content. The credential map rules inspect direct source text; they do not decode nested escaped documents.
Stage all intended release changes before relying on the candidate result. Ignored files and submodule contents are outside this check. The checker does not inspect Git history. Git LFS pointers fail the check because their external objects require separate review. Missing index blobs, including unavailable partial-clone objects, fail without network fetching. A symlink's own target text is scanned, while a symlinked parent component fails without reading outside the repository. Git's optional locks are disabled so read-only index operations do not freshen split-index metadata, and inherited Git trace-file destinations are cleared. BOM-marked UTF-16 source also requires separate review; the checker does not transcode or unpack content.
Semantic Review
Automation cannot decide whether prose, filenames, images, or other assets contain customer information, internal links, personal data, or company-only context. Inspect the complete tree before first publication and the exact diff for later releases. Mark this check unconfirmed unless a reviewer actually performed it.
GitHub-Native Controls
For an existing public GitHub repository, use read-only GitHub commands to confirm the live state rather than recreating GitHub policy logic locally:
gh repo view OWNER/REPO --json visibility,defaultBranchRef
gh api repos/OWNER/REPO --jq '{visibility,security_and_analysis}'
gh ruleset check --default --repo OWNER/REPO
gh ruleset list --repo OWNER/REPO --parents --limit 100
gh ruleset view RULESET-ID --repo OWNER/REPO
default_branch="$(gh repo view OWNER/REPO --json defaultBranchRef \
--jq '.defaultBranchRef.name')"
encoded_branch="$(ruby -rerb -e \
'print ERB::Util.url_encode(ARGV.fetch(0))' "$default_branch")"
gh api "repos/OWNER/REPO/branches/${encoded_branch}/protection"
gh api 'repos/OWNER/REPO/actions/runners?per_page=100' \
--jq '{total_count,runners:[.runners[] | {name,status,busy}]}'Inspect applicable rulesets and classic branch protection when necessary to confirm the required hosted check, update strictness, and bypass actors. A 404 from the classic endpoint means no classic rule is configured; it does not invalidate an applicable ruleset. If authorization cannot expose a setting, report it as unconfirmed. Do not weaken or mutate settings unless the user separately authorizes that action.
Result
Report these fields separately:
- repository verifier:
passed,failed, ornot available; - automated current-source check:
passedorfailed; - semantic context review:
confirmedorunconfirmed; - GitHub-native controls:
confirmed,unconfirmed, ornot applicable; - history review: normally
not performed; - bounded verdict:
readyonly when every check required for this release is passed or confirmed.
Do not summarize the bounded verdict as “the repository is safe.” Full-history investigation is a separate, exceptional workflow using established tooling. Publishing, rewriting history, revoking credentials, and changing repository settings remain separate actions requiring their own authorization.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

