Ten checks cover presentation, not software readiness
GitHub Launch Checklist asks whether a repository looks prepared for visitors. It checks the name, description, topic count, README length, license, homepage, installation text, contributing guide, issue templates, and social preview. The command prints a score, emits JSON if requested, and can exit with status 1 below a chosen threshold. That is useful as a memory aid before a public announcement.
The word readiness carries more weight than the code earns. None of the ten checks opens the source, runs the package, examines dependencies, verifies a release artifact, or looks for security policy beyond the license and community profile. A repository can score well while failing to build. Another can lose points for lacking a homepage even when its package and documentation are excellent. Read the result as a presentation checklist, not a product verdict.
The implemented maximum is 9.0, not 10
The social-preview check always returns manual because GitHub's API does not expose that setting. The scoring function gives 1 point to a pass and half a point to a warning, but gives no point to manual. The project's own test calls a repository with all 9 machine checks passing a perfect score and asserts 9.0. There is no input that turns social preview into a pass.
That conflicts with the README in two ways. The tool advertises ten checks scored 0 to 10, while the implementation tops out at 9.0. Its sample output shows 9.5/10 with social preview marked for manual inspection, which the current score() function cannot produce. This is visible in version 1.0.1, not an inference from our sandbox. Users setting --fail-under 10 create a gate that no repository can satisfy.
What happened when we ran it
Our sandbox installed commit 201a1a0 in 22 seconds, adding 36 packages and occupying 37 MB. The build succeeded in 4 seconds. The environment was a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, Python 3.12, and no secrets. Pip-audit reported 0 known vulnerabilities.
Pytest completed in 6 seconds with 26 passed and 0 failed. The checkout contained 32 files, about 372 lines of source, and used 0.3 MB before installation. The repository includes 4 CI workflow files, a Dockerfile, and a tests directory. These are strong mechanics for a tool this small. They prove the supplied checks behave as tested, including the 9.0 ceiling; they do not validate the tool's search or launch advice.
String matching makes several passes easy to earn
A repository name passes if it is at least 6 characters, contains a lowercase letter, and is not one of nine generic words. The function does not decide whether the name describes the software or matches a real search. A random lowercase string can receive the same point as a precise name. The output still labels that result descriptive and searchable, which overstates what was checked.
Installation detection is similarly broad. A README passes if its lowercase text contains one of several markers, including git clone, ## usage, or quick start. The command does not verify that the matching section contains a complete or working instruction. README quality is a word count: 300 words passes, 100 to 299 warns, and less than 100 fails. The 5-topic threshold is also fixed, regardless of project type.
These rules can still catch omissions. A missing license, empty About line, absent issue template, or README with no obvious start section is worth fixing. The trouble begins when the detail string turns a cheap proxy into a factual judgment. A better local use is to rename the result in your own process: it is a metadata lint score.
The Action is convenient for preventing regressions
The CLI runs on Python 3.9 or newer and depends on Requests. It accepts owner/repo, an optional GitHub token, JSON output, and either --strict or --fail-under. The composite GitHub Action installs Requests, uses the workflow token by default, and runs the same script. A Docker image provides a third route. Occasional checks of public repositories do not require sign-up.
As a regression gate, the hard-coded checks make more sense. If your project has decided it must keep a license, install section, 5 topics, and issue templates, a score below 8 can flag accidental removal. That still leaves an awkward property: one changed field can be hidden by another field improving. CI systems that care about a specific file should check that file directly instead of relying only on the total.
Version 1.0.1 shipped after one day of repository history
The repository was created and last pushed on September 17, 2026. Release v1.0.1 shipped that day with the GitHub Action, Docker image, and configurable failure threshold. GitHub showed 379 stars, 9 forks, and 0 open issues or pull requests when checked. Zero open items does not demonstrate long-term stability; here it accompanies a project whose visible code history spans one day.
Use GitHub Launch Checklist before announcing a small public repo, especially if you tend to forget the About line or community files. Its 26 passing tests and simple deployment paths make it easy to try. Keep the result in proportion. A 9.0 says nine metadata conditions matched; it does not say users can install the software, that GitHub will rank it, or that the launch is ready.