agentleFS
fiveonecodefiveonecode/agent-skills/public-source-release-audit/SKILL.md

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.

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
  1. Distinctive:

    Use this skill to answer a narrow question honestly: does the current source candidate contain a supported high-confidence leak, and have …

    line 8
  2. Distinctive:

    Run the repository's own verifier when it exists.

    line 14
  3. Distinctive:

    Do not summarize the bounded verdict as “the repository is safe.” Full-history investigation is a separate, exceptional workflow using …

    line 102

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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_, and github_pat_ token prefixes;
  • AWS AKIA/ASIA access-key IDs and canonical named 40-character secret access-key values;
  • OpenAI sk- and sk-proj- key prefixes;
  • explicit Authorization: Bearer header or map values; and
  • literal, commonly source-escaped, or file://-wrapped rooted POSIX families Users/<name>, var/root, private/var/root, home/<name>, and root, plus drive-letter Users\\<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, or not available;
  • automated current-source check: passed or failed;
  • semantic context review: confirmed or unconfirmed;
  • GitHub-native controls: confirmed, unconfirmed, or not applicable;
  • history review: normally not performed;
  • bounded verdict: ready only 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.