| name | public-release-readiness |
| description | Use when preparing this package for public release, npm publication, README/package metadata review, licensing notes, contribution docs, or repository hygiene. |
Public release readiness workflow
Use this skill for docs, package metadata, and publication-readiness work. Do not invent project decisions.
Review steps
- Inspect
package.json, README.md, CONTRIBUTING.md, AGENTS.md, .gitignore, and CI before editing.
- Keep installation wording honest until the package is actually published. Prefer local/path or future-publication wording over implying npm availability.
- Remove or avoid nonexistent repository URLs, package URLs, security contacts, maintainers, or governance claims.
- State licensing status accurately. Add a
LICENSE only after the project owner has selected a license.
- Confirm public examples contain no secrets, private AWS account details, project-specific identifiers, sibling paths, or sibling-repo dependencies. Package code must remain standalone.
- Keep quality policy visible:
bun run verify, coverage thresholds, and per-production-function CRAP <= 6.
- Run
bun run verify after docs/config changes when feasible, because docs must not undermine existing guarantees.
Handoff notes
Report files changed, publication blockers, verification results including max CRAP, and remind the user to restart opencode after skill/config changes.
