oss-readiness-audit

Solid

Systematic pre-publish audit for a project about to go public on GitHub (open source release or portfolio piece). Use when a repo is about to get its first commit/push, or when the user says things like "ready to publish", "open source my project", "push to GitHub first time", "portfolio repo review", "is this repo ready for GitHub", "can I make this public", or asks to check for secrets/leftover artifacts before sharing a repo. Walks a checklist covering git repo scope, .gitignore coverage, secrets/PII sweep, LICENSE, README completeness, misleading naming, internal process docs, doc consistency, and CI — gathering evidence with shell commands and producing a blocker/recommended/nice-to-have report. Language-agnostic across Swift, Node, Python, Rust, Go, etc. Trigger with "/oss-readiness-audit".

Code & Development 0 stars 0 forks Updated 5 days ago MIT

Install

View on GitHub

Quality Score: 78/100

Stars 20%
0
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# OSS Readiness Audit ## Overview A pre-publish checklist for a repo that is about to become public on GitHub. Run every check below, gather the evidence with the given commands, then produce the report in the template at the end. ## Prerequisites - `git` plus standard Unix shell tools (`grep`, `find`, `du`) — nothing language-specific; the checks work the same on Swift, Node, Python, Rust, or Go projects. - Read access to the full project tree, including dotfiles. **Golden rule: fix every BLOCKER before the first commit, not after.** Once a commit lands, its content lives in `.git` history forever — even if a later commit deletes it, anyone who clones the repo can still recover the old blob. A `.gitignore` added after the fact does not retroactively remove already-tracked files, and history rewrites (`git filter-repo`, BFG, `reset --hard` + fresh init) are only cheap and safe while the repo has never been pushed. So: run this audit, fix blockers, THEN `git init` / first commit, THEN push. If the repo already has commits and/or has already been pushed, say so explicitly in the report — the remediation for a blocker changes from "fix before committing" to "history surgery required, and rotate any leaked secret immediately." --- ## How to use 1. Confirm the project root directory with the user if it's ambiguous. 2. Go through items 1–10 in order. For each: run the commands, note pass/fail, and collect the evidence (file paths, byte counts, match counts) you'll n...

Details

Author
chsistrying
Repository
chsistrying/swift-ship-skills
Created
6 days ago
Last Updated
5 days ago
Language
Shell
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Listed

oss-launch

Use when taking a repo open source, or hardening one that already is. Run /oss-launch and it scans the repo (stack, existing files, git remote, secrets), asks only what it cannot infer, then generates a tailored OSS file collection (README, LICENSE, CONTRIBUTING, CODE_OF_CONDUCT, SECURITY, CHANGELOG, .gitignore, .github/ issue + PR templates, CI/CD). Also covers launch (GitHub metadata, badges, Show HN, Reddit, YouTube), release cadence (SemVer + CHANGELOG), and demo-GIF generation. Triggers on "open source this", "OSS checklist", "prep for launch", "make this repo public", "add a license / contributing / security policy", "Show HN", "release workflow", "star growth", "get contributors".

8 Updated 5 days ago
AnayDhawan
AI & Automation Listed

release-audit

Release & supply-chain readiness audit: gathers evidence from real workflows, manifests, and repo settings, compares against a gold-standard reference stack, has an adversarial subagent try to refute the draft, and returns a prioritized action plan (P1–P3) whose fixes are delegated to the sibling setup skills. Use when asked to audit release automation, publishing security, CI or supply-chain maturity, or whether a repo is ready to release. For a whole-repo health check (docs, tests, code quality) use maturity-analysis instead.

0 Updated today
emaarco
AI & Automation Listed

publish-readiness

Use before making a private repository public, before the first push of a new public repo, or when the user asks "is this safe to publish", "check for leaks", or wants a pre-publication scan. Also use after discovering identifying content already leaked into a public repo's history.

2 Updated today
escoffier-labs