tenferro-release-publish

Estrellas64

Forks2

Actualizado4 de julio de 2026 a las 08:44

Release a new tenferro-rs version. Use for workspace version bumps, tagging, crates.io publication in dependency order, and post-publish provenance verification. Publishing is irreversible and requires maintainer crates.io ownership. Do not use for ordinary feature or bug-fix PRs, and never publish from an unpushed or untagged commit.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

tensor4all

tensor4all/tenferro-rs

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·SOC 15-1252

SKILL.md

readonly

name	tenferro-release-publish
description	Release a new tenferro-rs version. Use for workspace version bumps, tagging, crates.io publication in dependency order, and post-publish provenance verification. Publishing is irreversible and requires maintainer crates.io ownership. Do not use for ordinary feature or bug-fix PRs, and never publish from an unpushed or untagged commit.

Tenferro Release And Publish

Follow ai/contribution-workflows/release-publish.md as the canonical workflow. Read it fully before acting.

Hard invariants (abort the release if any would be violated):

Publish only from a pushed, tagged, main-lineage commit.
The version bump merges to main before anything is published.
No manifest edits at publish time; fix on main and re-tag instead.
Git-pinned workspace dependencies must pin revs whose declared versions exist on crates.io.

Keep the interaction incremental:

Confirm the target version and that origin/main is green and clean.
Phase 1: version-bump PR (workspace version plus every internal cross-crate version = "..." requirement) and the full pre-push checklist.
Phase 2: tag the merged commit and push the tag.
Phase 3: publish crates in dependency order from a worktree of the tag, waiting for the registry index between crates. Confirm with the user immediately before the first cargo publish.
Phase 4: verify crates.io versions and .cargo_vcs_info.json provenance, then clean up.

Más de este repositorio

mismo repositorio

tenferro-bugfix-pr

tensor4all/tenferro-rs

Prepare a tenferro-rs bug-fix PR for existing intended behavior. Use for regression fixes, panic fixes, wrong-result fixes, compatibility fixes, related bug batches, repository-rule audit findings, same-root-cause bug sweeps, and false-positive bug reports that need source comments or source-contract tests. Do not use for new features, new public APIs, new backends, new dependencies, feature flags, or architectural changes; redirect those to issue intake.

2026-06-1764

tenferro-bugfix-pr

tensor4all/tenferro-rs

2026-06-1764

tenferro-issue-intake

tensor4all/tenferro-rs

Create or refine tenferro-rs GitHub issues through a step-by-step intake workflow. Use for bug reports, feature requests, design discussion issues, documentation issues, article-topic issues, and when a user proposes a new feature PR that must be redirected to an issue first. Do not use for implementation work.

2026-05-2764

tenferro-issue-intake

tensor4all/tenferro-rs

2026-05-2764

name	tenferro-release-publish
description	Release a new tenferro-rs version. Use for workspace version bumps, tagging, crates.io publication in dependency order, and post-publish provenance verification. Publishing is irreversible and requires maintainer crates.io ownership. Do not use for ordinary feature or bug-fix PRs, and never publish from an unpushed or untagged commit.

Tenferro Release And Publish

Follow ai/contribution-workflows/release-publish.md as the canonical workflow. Read it fully before acting.

Hard invariants (abort the release if any would be violated):

Publish only from a pushed, tagged, main-lineage commit.
The version bump merges to main before anything is published.
No manifest edits at publish time; fix on main and re-tag instead.
Git-pinned workspace dependencies must pin revs whose declared versions exist on crates.io.

Keep the interaction incremental:

Confirm the target version and that origin/main is green and clean.
Phase 1: version-bump PR (workspace version plus every internal cross-crate version = "..." requirement) and the full pre-push checklist.
Phase 2: tag the merged commit and push the tag.
Phase 3: publish crates in dependency order from a worktree of the tag, waiting for the registry index between crates. Confirm with the user immediately before the first cargo publish.
Phase 4: verify crates.io versions and .cargo_vcs_info.json provenance, then clean up.