agentleFS
Jawahars07Jawahars07/ballast/skills/github-publish/SKILL.md

github-publish

Skill1 starsChanged 2 months agoMITView on GitHub

Take a local project public safely - sweep for secrets including the full git history, harden real weaknesses like plaintext credentials, strip copyrighted and bloat files, write a README from verified claims only, and enable repo security features. Use when asked to publish, open-source, or push a project to GitHub.

  • Reads credentials

4 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 5 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Treat every publish as a security review of the code, not only of the secrets.

    line 49
  2. Distinctive:

    Real shipped claims only: If a number is illustrative or seeded rather than measured, label it as such on the page.

    line 65
  3. Distinctive:

    Create the repo with a clear description.

    line 76
  4. Very specific:

    Add SECURITY.md with a reporting path

    line 82
  5. Very specific:

    Add a LICENSE. An unlicensed public repo is legally "all rights reserved", which means nobody can use it, which defeats the point

    line 83
  6. Distinctive:

    Consider release tags, so people can pin rather than track a moving main

    line 86
  7. Distinctive:

    Update your own notes or knowledge base with the repo status and URL.

    line 90

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

GitHub Publish

Publishing is irreversible. A secret pushed to a public repo is compromised the moment it lands, and deleting the commit does not un-compromise it — it is already in forks, mirrors, and scrapers within minutes.

So the sweep comes first, every time, and the push is the last step.

Step 1 — Secret sweep, before anything else

The working tree is not enough. Check the full history.

# every file ever committed that looks like a secret carrier
git log --all --name-only --pretty=format: | sort -u | grep -iE '\.env|\.pem$|\.key$|id_rsa|credentials|secrets?\.(ya?ml|json)'

# high-signal patterns across all history
git grep -nE '(sk-[A-Za-z0-9]{20,}|ghp_[A-Za-z0-9]{20,}|AKIA[0-9A-Z]{16}|-----BEGIN [A-Z ]*PRIVATE KEY-----)' $(git rev-list --all) 2>/dev/null | head -20

# working tree
grep -rnE '(api[_-]?key|secret|password|token)\s*[=:]\s*["\x27][^"\x27]{12,}' . --exclude-dir=.git --exclude-dir=node_modules | head -20

A dedicated scanner such as gitleaks detect --no-git=false is worth running as well. Do not rely on it alone; do not skip it either.

If the history is dirty, it must be rewritten or the repo re-initialised before pushing. There is no "we'll clean it up after" option here.

Then confirm:

  • .env is gitignored, and only .env.example with empty labelled keys is public
  • Code reads keys from the environment. No hardcoded credentials anywhere
  • A .gitignore appropriate to the language exists at all

Step 2 — Harden what the sweep exposes

Publishing forces the security bar up, and that is a feature. Fix what you find:

  • Plaintext passwords → salted hashes
  • Database credentials → environment variables
  • Overly-permissive CORS, debug modes, default admin accounts left on

Treat every publish as a security review of the code, not only of the secrets.

Step 3 — Strip what does not belong

  • Copyrighted material. Cite it, do not commit it. A base research paper gets a citation and a link, not a PDF in the repo. Check dataset licenses; permissively-licensed data is fine with attribution.
  • Bloat. Duplicate archives, build artifacts, scratch and extraction directories. Extract what you need, delete the scratch, never commit it.
  • Anything personal that is not the point of the repo. Local paths with your username, private notes, screenshots with credentials or personal data in them.

Step 4 — Write the README from verified claims only

What it is, the honest headline result, the stack, and how to run it.

Real shipped claims only. If a number is illustrative or seeded rather than measured, label it as such on the page. Presenting example figures as real usage is the same failure as fabricating them.

Step 5 — Name it properly the first time

Descriptive kebab-case. vehicle-co2-emission-prediction, not project1. Bad names stick, and renaming later breaks every link anyone has shared.

Step 6 — Publish, then verify the remote

Create the repo with a clear description. Push. Then browse the pushed tree and confirm it is clean. Do not assume the ignore rules worked — look.

Step 7 — Repo hygiene

  • Enable Dependabot alerts and automated security fixes
  • Add SECURITY.md with a reporting path
  • Add a LICENSE. An unlicensed public repo is legally "all rights reserved", which means nobody can use it, which defeats the point
  • Enable branch protection on the default branch if others will contribute
  • Consider release tags, so people can pin rather than track a moving main

Step 8 — Close the loop

Update your own notes or knowledge base with the repo status and URL. A publish that is not recorded is invisible to every future session.

Mistakes that have actually happened

  • A live API key sat in a .env in a project queued for publishing. It was caught by the sweep and the project stayed unpublished until verified clean. Never publish on the assumption the ignore rule works — verify staging and the remote after pushing.
  • Plaintext passwords in a database-backed project were found at publish time and converted to salted hashes. The publish is what surfaced them.
  • 150MB of duplicate zip archives were dropped pre-publish, and a 94MB scratch directory was deleted afterward. Both would have been permanent in the history.
  • A copyrighted base paper was excluded and cited instead. Do not push other people's PDFs or datasets without reading the license.
  • project1 had to be renamed later. Name it properly the first time.

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.