rust-cli-publish

name	rust-cli-publish
description	Publish stage for the rust-cli skill family: close the workflow with repository-owned packaging and release actions, including report-only summaries, dry runs, exact-mirror rehearsals, destination configuration checks, and the supported GitHub Actions publication path.

rust-cli Publish

Use this stage when the package has reached its final lifecycle phase after validation and the next job is report-only closure, dry-run review, rehearsal, or the supported real publication path.

When To Use This Stage

• Validation has succeeded and the workflow needs final closure.
• The user wants release readiness without running release commands.
• The user wants a local dry run, exact-mirror rehearsal, destination-config review, or the supported real publication workflow.

Stage Goal

Complete the requested release activity with the correct level of certainty:

• report-first no-publish closure
• repository-owned packaging review that consumes generated package inputs
• local dry-run review
• exact-mirror rehearsal
• or the documented real GitHub Actions release path

Do not collapse those into a single meaning. Generated skills may contribute package-local packaging-ready metadata or support fixtures, but repository-owned CI workflows and release scripts remain outside generated skill packages.

Canonical References

• ../../docs/release/skill-release-runbook.md
• ../../.github/workflows/release.yml
• ../../release/skill-release.config.json
• ../../package.json

Read the runbook first, then use the workflow, release config, and package scripts as the implementation-specific release surfaces.

Required Inputs

• the intended release mode:
  • report_only
  • dry_run
  • rehearsal
  • live_release
• the current validation status for the latest substantive change
• the generated package inputs and any package-local support assets that the selected packaging path expects
• destination repository configuration strategy: tracked config, environment override, or workflow dispatch override
• credentials appropriate to the chosen mode

Prerequisites

• The release branch should be ready and follow the commit policy documented in the runbook.
• Real release flow expects main as the source release branch.
• Local review uses the documented Node.js and npm baseline.
• Dry runs need a valid GITHUB_TOKEN or GH_TOKEN that can authenticate the source repository.
• Real cross-repository publication needs DESTINATION_REPOSITORY_TOKEN.

Workflow

1. Read ../../docs/release/skill-release-runbook.md and confirm which release mode the user wants.
2. Confirm the release prerequisites that match that mode:
   • validation is current for the latest meaningful change
   • the generated package boundary is satisfied and any package-local support assets required by the chosen path are present
   • destination configuration is available through tracked config, env var, or workflow dispatch override
   • required credentials are present for the chosen path
3. If no explicit release action was requested, default to report_only:
   • summarize release readiness, blockers, and next actions
   • point to dry_run, rehearsal, and live_release as explicit follow-up modes
   • do not run release commands
4. Verify the formatting baseline with npm run format:check before any mode that executes release tooling.
5. For local dry-run review:
   • run GITHUB_TOKEN=<valid token> npm run release:dry-run
   • inspect whether semantic-release reports a real release or a no-release outcome
   • review the prepared release behavior without claiming a destination publish occurred
6. For exact-mirror rehearsal:
   • run the documented scripts/release/publish-skill-to-target-repo.mjs rehearsal command with a non-placeholder destination slug or local target
   • inspect .work/release/publish/, .work/release/last-publication-receipt.json, and .release-manifest.json
   • confirm the exact-mirror tree contains the expected published files
   • distinguish repository-owned packaging evidence from final distributable outputs so the rehearsal is not mistaken for a generated skill package
7. For the real release path:
   • follow the GitHub Actions workflow in ../../.github/workflows/release.yml
   • the supported path is push or dispatch into the workflow, not pretending a local dry run completed the production publish
   • expect the workflow to run npm ci, npm run format:check, node scripts/release/verify-release-config.mjs, npm run release:ci, destination commit message preparation, and the peaceiris publish step
8. If release blockers appear, use the runbook's failure recovery guidance for missing credentials, placeholder destination config, missing runtime destination config, or no-release outcomes.

Guardrails

• Do not describe local dry-run or rehearsal as if it created the production release.
• Do not imply that repository-owned CI workflows or release scripts are copied into generated skill packages.
• report_only is the default mode when the user did not explicitly request a release action.
• Do not skip validation when the latest substantive change has not been checked yet.
• Use the documented destination resolution order instead of inventing a custom configuration path.
• Do not claim the destination repository receives a matching tag or GitHub Release; the runbook explicitly says it does not.

Done Condition

This stage is complete only when the requested release activity has been performed or reviewed and the user has a clear outcome:

• report_only readiness summary
• dry-run result
• rehearsal evidence
• or the supported real release path plus any remaining workflow follow-up

Next Step

• Stop after dry-run or rehearsal if the user asked only for release preparation.
• Stop after report_only if the user needed only final closure and readiness guidance.
• After a real release trigger, monitor or verify the resulting publication evidence using the workflow outputs and prepared publication artifacts.