Release

4. Update release files only.

• apps/cli/package.json
• CHANGELOG.md
• release-facing docs when needed

5. Update the changelog in user-facing language.

• Keep ## Unreleased at the top.
• When cutting a release, move relevant entries into a dated version section.
• Do not use internal terminology when a user-facing phrase is clearer.

6. Re-run validation and show the diff.

• Run pnpm release:check again.
• Show the diff before any commit, tag, or publish operation.

Package Validation

Use pnpm release:check as the default validation command.

When checking package contents, the tarball should contain only:

• dist
• README.md
• package.json

It must not contain:

• src
• test
• .turbo
• TypeScript config files
• Vitest config files

Direct package-level check:

npm_config_cache=/tmp/codex-su-npm-cache npm pack --dry-run

from apps/cli.

Response Contract

When using this skill, provide:

1. The current version and proposed next version.
2. The exact release files changed.
3. The validation result from pnpm release:check.
4. Any blockers to publishing readiness.

Future Publish Flow

If the user later asks to publish:

1. Confirm codex-su is still the intended npm package name.
2. Re-run pnpm release:check.
3. Confirm npm auth and package visibility settings.
4. Publish from apps/cli, never the repo root.
5. Verify install and codex-su version after publish.

Guardrails

• Never publish the root package.
• Never publish without an explicit user request.
• Never broaden metadata with internal terminology when user-facing phrasing is clearer.
• Prefer concise metadata and concise release notes.