| name | repo-public-release-checklist |
| description | Prepare a local project for a first public GitHub release without leaking internal AI/session artifacts. |
| domain | release |
| confidence | high |
| source | earned |
Context
Use this when promoting a locally developed project to its first public GitHub repo, especially when the working directory contains internal AI/team state, capture files, editor caches, or local automation scaffolding.
Rules
- Read any internal directives first and identify folders/files that must never be published.
- Audit public docs for internal path references, stale architecture text, missing install URLs, and missing status disclaimers.
- Ensure manifest/package metadata matches the release version, author, documentation link, and raw GitHub URLs before pushing.
- Add ignore rules before
git add .; at minimum cover internal coordination dirs (for example .squad/, .copilot/), packet captures, editor state, and machine-local caches.
- Inspect
git status --short before committing and explicitly verify excluded paths are not staged.
- Watch for non-obvious local artifacts outside the obvious internal dirs (for example
.vs/, .github/agents/, internal workflows, or .gitattributes files that only exist to support local team tooling).
- Commit first, then create/publish the GitHub repo, and verify the remote tree through the GitHub API.
- Confirm the HPM/raw-install URL resolves publicly after push.
Examples
hubitat-drivers v0.4.0 public release on 2026-05-16
- Repo:
https://github.com/madskristensen/hubitat-drivers
- HPM:
https://raw.githubusercontent.com/madskristensen/hubitat-drivers/main/drivers/gemstone-lights/packageManifest.json
Anti-Patterns
- Running
git add . before the ignore rules exist
- Publishing
.squad/, .copilot/, .pcap, or editor/system caches
- Leaving user docs pointing at internal paths or internal code names
- Assuming only
.squad/ is private and missing adjacent local automation files under .github/
