Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

release-publish

Étoiles4

Forks0

Mis à jour11 juillet 2026 à 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

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

ronsse

ronsse/trellis-ai

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·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.

Plus depuis ce dépôt

même dépôt

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.