Run any Skill in Manus with one click

release-publish

Stars4

Forks0

UpdatedJuly 11, 2026 at 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

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

ronsse

ronsse/trellis-ai

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·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.

More from this repository

same 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.