tenferro-release-publish

Estrelas64

Forks2

Atualizado4 de julho de 2026 às 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.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

tensor4all

tensor4all/tenferro-rs

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Desenvolvedores de softwareInformática e Matemática·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.

Mais deste repositório

mesmo repositório

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.