tenferro-release-publish

Sterne64

Forks2

Aktualisiert4. Juli 2026 um 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.

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

In Manus ausführen

Quelle

tensor4all

tensor4all/tenferro-rs

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

In Manus ausführen

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

SoftwareentwicklerInformatik- und Mathematikberufe·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.

Mehr aus diesem Repository

gleiches Repository

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.