Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

release-publish

Sterne4

Forks0

Aktualisiert11. Juli 2026 um 21:30

Cut and publish a trellis-ai release to PyPI via the tag-triggered GitHub workflow. Use when asked to "cut a release", "publish to PyPI", "tag a version", or "ship vX.Y.Z". Do not use for refreshing the skynet deployment — that is the skynet-hub stack rebuild (see step 6), which this skill only reminds about.

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

ronsse

ronsse/trellis-ai

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	release-publish
description	Cut and publish a trellis-ai release to PyPI via the tag-triggered GitHub workflow. Use when asked to "cut a release", "publish to PyPI", "tag a version", or "ship vX.Y.Z". Do not use for refreshing the skynet deployment — that is the skynet-hub stack rebuild (see step 6), which this skill only reminds about.

Release trellis-ai to PyPI

Versioning is hatch-vcs: the version derives from the git tag — there is no version field to bump. The v* tag push IS the release trigger.

Preflight — clean tree on main, up to date with origin, CI green:

git status --porcelain          # must be empty
git pull --ff-only
gh run list --branch main -L 4  # Tests/Lint/Type Check green on HEAD

Local artifact sanity (optional but cheap):

make publish-check              # python -m build + twine check dist/*

Pick the version — semver against the last tag:
```
git describe --tags --abbrev=0  # e.g. v0.9.0
```
Scan git log <last-tag>..HEAD --oneline for breaking changes (major), features (minor), fixes only (patch). Confirm the number with the owner if it is a major bump.
Tag and push — this triggers .github/workflows/publish.yml (test matrix py3.11–3.13, then OIDC trusted-publish, environment pypi):
```
git tag vX.Y.Z
git push origin vX.Y.Z
```

Watch and verify:

gh run watch $(gh run list --workflow publish.yml -L 1 --json databaseId -q '.[0].databaseId')
pip index versions trellis-ai   # new version listed

Remind about the skynet deployment — publishing does NOT update the running instance. The trellis-api container builds from the local checkout and drifts (see ~/projects/skynet-hub/stacks/trellis/drift-and-redeploy.md); offer the rebuild as a follow-up. The host-side CLI/MCP track the working tree automatically (editable venv) — nothing to do there.

Gotchas

The tag must point at a commit already on origin/main — tagging an unpushed commit publishes something CI never saw.
Re-running a failed publish: use the workflow's workflow_dispatch with ref set to the tag (a bare re-run of a tag push can lose the ref).
hatch-vcs needs full history (fetch-depth: 0 — already set in the workflow); a shallow local build shows a .devN version, which is normal locally and wrong only if it appears in CI.

Mehr aus diesem Repository

gleiches Repository

link-evidence

ronsse/trellis-ai

When you discover a durable fact (an API contract, a config value, a service ownership, a non-obvious gotcha), store it in Trellis as a memory and connect it to the relevant entity in the knowledge graph. This makes the fact retrievable from any future task that touches the same area.

2026-06-124

record-after-task

ronsse/trellis-ai

After completing meaningful work, write a structured trace to Trellis with steps + outcome, then record success/failure feedback. This is what makes future runs of retrieve-before-task useful — without it, the institutional memory is empty.

2026-06-124

retrieve-before-task

ronsse/trellis-ai

Pull a token-budgeted context pack from Trellis (prior traces, precedents, evidence, knowledge graph) before starting non-trivial work. Use whenever the task is more than a one-line tweak — investigations, refactors, new features, debugging, design decisions.

2026-06-124

trellis-ai

ronsse/trellis-ai

Structured institutional memory for AI agents — traces, precedents, knowledge graph, temporal versioning, and governed mutations. Complements built-in memory with structured knowledge.

2026-05-124

name	release-publish
description	Cut and publish a trellis-ai release to PyPI via the tag-triggered GitHub workflow. Use when asked to "cut a release", "publish to PyPI", "tag a version", or "ship vX.Y.Z". Do not use for refreshing the skynet deployment — that is the skynet-hub stack rebuild (see step 6), which this skill only reminds about.

Release trellis-ai to PyPI

Versioning is hatch-vcs: the version derives from the git tag — there is no version field to bump. The v* tag push IS the release trigger.

Preflight — clean tree on main, up to date with origin, CI green:

git status --porcelain          # must be empty
git pull --ff-only
gh run list --branch main -L 4  # Tests/Lint/Type Check green on HEAD

Local artifact sanity (optional but cheap):

make publish-check              # python -m build + twine check dist/*

Pick the version — semver against the last tag:
```
git describe --tags --abbrev=0  # e.g. v0.9.0
```
Scan git log <last-tag>..HEAD --oneline for breaking changes (major), features (minor), fixes only (patch). Confirm the number with the owner if it is a major bump.
Tag and push — this triggers .github/workflows/publish.yml (test matrix py3.11–3.13, then OIDC trusted-publish, environment pypi):
```
git tag vX.Y.Z
git push origin vX.Y.Z
```

Watch and verify:

gh run watch $(gh run list --workflow publish.yml -L 1 --json databaseId -q '.[0].databaseId')
pip index versions trellis-ai   # new version listed

Remind about the skynet deployment — publishing does NOT update the running instance. The trellis-api container builds from the local checkout and drifts (see ~/projects/skynet-hub/stacks/trellis/drift-and-redeploy.md); offer the rebuild as a follow-up. The host-side CLI/MCP track the working tree automatically (editable venv) — nothing to do there.

Gotchas

The tag must point at a commit already on origin/main — tagging an unpushed commit publishes something CI never saw.
Re-running a failed publish: use the workflow's workflow_dispatch with ref set to the tag (a bare re-run of a tag push can lose the ref).
hatch-vcs needs full history (fetch-depth: 0 — already set in the workflow); a shallow local build shows a .devN version, which is normal locally and wrong only if it appears in CI.