Originally published at https://tateprograms.com/release-readiness-2026.html. A lot of repos look finished right before they are published. The README has a screenshot. The package builds locally. The demo runs once. The launch post is drafted. That is usually the riskiest moment, because the parts that fail in public are rarely the parts that looked exciting while building. They are the boring edges: install instructions, CI, package metadata, secret handling, publish workflows, screenshots, old config files, and the difference between a demo and something another developer can actually run. This is the release-readiness checklist I use for JavaScript and TypeScript projects before they go public. If the answer depends on me sitting next to them, it is not ready. Minimum bar: A clear install command. A clear local dev command. A clear test or check command. Required environment variables listed in .env.example. No hidden dependency on files that only exist on my machine. For npm packages, I want the package to pass a real install path, not just a local script: npm pack --dry-run npm exec --yes --package @latest The dry run catches a surprising amount: missing files, wrong files config, stale build output, and packages that work in the repo but not after publish. A README that says "run npm test" should have CI that runs it. I look for: A GitHub Actions workflow on pull requests or pushes. The same commands documented in the README. A lockfile committed for apps and CLIs that expect repeatable installs. No workflow that only checks formatting while skipping build/test. For developer tools, CI is also part of the product. If a CLI or Action claims to help release projects, the project itself should show a working release path. Bad metadata does not just look sloppy. It breaks discovery and trust. I check: name, description, license, repository, homepage, and bugs. The bin entry for CLIs. The package contents included in publish. Version consistency across files that repeat it. This matters even more for MCP servers because metadata can exist in multiple places. If package.json, server.json, registry metadata, and README instructions drift apart, users cannot tell which install path is current. The common failure is not a committed production key. It is a repo that teaches contributors to create one. I want: .env, .env.local, and local secret files ignored. .env.example committed. Docs that name required variables without including real values. No screenshots or demo videos showing private tokens. No config that encourages pasting long-lived tokens into random terminals. Release workflows deserve the same treatment. Long-lived npm tokens are still common, but OIDC/trusted publishing is a better default for public packages when the platform supports it. For GitHub Actions, I check the workflow and marketplace surface separately. Questions: Does the Action run on a real fixture repo? Does it produce the advertised output? If it emits SARIF, does the SARIF validate? Are permissions narrowed instead of using broad defaults? Is the marketplace listing consistent with the README? An Action that looks good in action.yml can still fail as soon as another repo consumes it. MCP has moved from experiment to ecosystem surface. That means launch metadata matters. I check: Is there a working install command? Is the server name consistent across docs and metadata? Are supported tools described clearly? Does the README explain credentials, filesystem access, and network access? Does the server expose a smoke-test path? Are auth boundaries clear for remote servers? The 2026 MCP roadmap calls out registry and crawler discovery as part of the ecosystem's next phase. That makes public metadata a real interface, not just documentation. Agent-commerce and HTTP-native payment demos are getting real fast. x402, for example, is built around payment-required API calls instead of traditional account checkout. That changes the release checklist. A payment-agent demo should not only prove that payment works. It should prove that failure is contained. I look for: Sandbox or testnet mode by default. Explicit spend caps. Human approval before real payment. Recipient validation. Replay protection. Receipts or audit logs. Clear refund/failure behavior. Webhook or callback signature verification. No private payment metadata in public logs. The mistake to avoid is treating a money-moving demo like a normal API demo. It is not normal once a bug can spend funds. For launch work, I like a written report because it forces the checks to be specific. A useful report includes: Score or verdict. Evidence from file paths. Top risks. Priority fixes. Exact commands that were run. What was not checked. This is better than a vague "looks good" because it gives the builder a handoff artifact. Before sharing, I compare: npm package page. GitHub README. GitHub Marketplace page if there is an Action. MCP registry/directory listing if there is a server. Product page. Screenshots. Small mismatches make people hesitate. If the site says one command and npm says another, the buyer or maintainer has to do trust work before they even try the tool. I got tired of checking the same launch edges manually, so I built Shipcheck. It is a CLI that scans JavaScript and TypeScript repos for release-readiness issues across docs, package metadata, CI, env hygiene, npm publishing, GitHub Actions, MCP metadata, and payment-agent demo safety. Run it from a repo: npx --yes shipcheck-cli . It can export text, Markdown, JSON, and SARIF, so the output can be used as a local checklist, a pull-request artifact, or a code-scanning report. The goal is not to replace judgment. The goal is to catch the launch problems that are easy to miss while everyone is focused on the demo. Shipcheck: https://tateprograms.com/shipcheck.html x402: https://www.x402.org/ MCP 2026 roadmap: https://blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/