oss-readiness-audit
SolidSystematic 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".
Install
Quality Score: 78/100
Skill Content
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
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".
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.
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.