Package release
Multi-persona workflow for releasing TTA.dev packages to PyPI with full quality validationFrom its SKILL.md
npx -y skills add theinterneti/TTA.dev --skill package-releaseAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
5.5 KB, ~1.5k tokens by cl100k_base, as published. Nobody here has run it
Package Release Skill
Overview
Orchestrates Backend Engineer → Testing Specialist → DevOps Engineer for safe, validated
releases of the active root ttadev package.
[!WARNING] Current release automation targets the root
ttadevpackage and thepackages/ttadev/v{semver}tag format.Older
tta-dev-primitives,platform/primitives, and token-based release steps belonged to an earlier package layout. Use the workflow-basedrelease.yml+publish.ymlflow below instead.
Prerequisites
Before starting:
- ✅ Clean git working directory
- ✅ All local quality gates passing
- ✅ On
mainor a release branch - ✅ GitHub access to push tags and inspect workflow runs
- ✅ PyPI trusted publisher configured for
.github/workflows/publish.yml
Verify:
git status
.github/copilot-hooks/post-generation.sh
git branch --show-current
gh workflow view release.yml
gh workflow view publish.yml
Stage 1: Prepare Release (Backend Engineer)
Goal: bump the root package version, update release notes, and prepare the repo.
Step 1.1: Determine the version bump
LAST_TAG=$(git tag --list 'packages/ttadev/v*' --sort=-version:refname | head -1)
if [ -n "$LAST_TAG" ]; then
git log "$LAST_TAG"..HEAD --oneline
else
git log --oneline
fi
Choose:
- Patch for fixes only
- Minor for backward-compatible features
- Major for breaking changes
Step 1.2: Update the root version
OLD_VERSION=$(grep '^version =' pyproject.toml | cut -d'"' -f2)
NEW_VERSION="0.1.1"
sed -i "s/^version = \"$OLD_VERSION\"/version = \"$NEW_VERSION\"/" pyproject.toml
grep '^version =' pyproject.toml
Step 1.3: Update release notes
Add the new section to CHANGELOG.md and review any pinned version references in active docs:
grep -n "0\\.1\\.0\\|0\\.1\\.1" README.md GETTING_STARTED.md PUBLISHING.md || true
Step 1.4: Commit release preparation
git add pyproject.toml CHANGELOG.md README.md GETTING_STARTED.md PUBLISHING.md
git commit -m "chore(release): prepare ttadev v$NEW_VERSION"
git push origin main
Handoff: @testing-specialist Release prep is pushed; validate the gates.
Stage 2: Quality Validation (Testing Specialist)
Goal: confirm the repo is green before any tag is pushed.
Step 2.1: Run the standard gate
.github/copilot-hooks/post-generation.sh
Step 2.2: Optional deeper validation
uv run pytest -v --tb=short -m "not integration and not slow and not external"
uv build --out-dir dist
ls -lh dist/
rm -rf dist
Step 2.3: Check CI status
COMMIT_SHA=$(git rev-parse HEAD)
gh run watch "$(gh run list --commit "$COMMIT_SHA" --json databaseId -q '.[0].databaseId')"
gh run list --commit "$COMMIT_SHA" --json conclusion -q '.[0].conclusion'
Pass criteria
- ✅ Standard repo gate passes
- ✅ CI checks are green
- ✅ Root package builds successfully
- ✅ No release-blocking issues remain
Handoff: @devops-engineer Quality gates passed; proceed with release workflows.
Stage 3: Deploy and Verify (DevOps Engineer)
Goal: create the release tag, let GitHub create the release, and optionally publish to PyPI.
Step 3.1: Create and push the release tag
git tag "packages/ttadev/v$NEW_VERSION"
git push origin "packages/ttadev/v$NEW_VERSION"
git tag --list "packages/ttadev/v$NEW_VERSION"
Step 3.2: Verify the GitHub Release workflow
release.yml triggers automatically from the pushed tag.
gh run watch "$(gh run list --workflow=release.yml --json databaseId -q '.[0].databaseId')"
gh release view "packages/ttadev/v$NEW_VERSION"
Step 3.3: Trigger PyPI publish
publish.yml is manual and uses GitHub OIDC trusted publishing.
gh workflow run publish.yml -f tag="packages/ttadev/v$NEW_VERSION"
gh run watch "$(gh run list --workflow=publish.yml --json databaseId -q '.[0].databaseId')"
uv pip index versions ttadev | head -5
Step 3.4: Post-release verification
docker run --rm -t python:3.11 bash -lc "
pip install ttadev==$NEW_VERSION &&
python -c 'import ttadev; print(ttadev.__file__)'
"
Success Criteria
Release is successful when:
- ✅
pyproject.tomlversion is updated - ✅
CHANGELOG.mdreflects the release - ✅ Local and CI quality gates are green
- ✅ Git tag exists in the form
packages/ttadev/vX.Y.Z - ✅
release.ymlcreated the GitHub Release - ✅
publish.ymlpublishedttadevto PyPI - ✅ Users can install the released version
Rollback Procedure
If a release goes bad:
1. Yank the PyPI release
Use the PyPI web UI for the ttadev project to yank the bad release if necessary.
2. Delete the release tag
git tag -d "packages/ttadev/v$NEW_VERSION"
git push origin :"refs/tags/packages/ttadev/v$NEW_VERSION"
3. Prepare a hotfix
git checkout -b hotfix/ttadev-v$NEW_VERSION-fix
# apply fix
git commit -am "fix: critical issue in ttadev v$NEW_VERSION"
Common Issues
Issue: Standard gate fails
Solution: fix the failing lint, type, or test checks before tagging.
Issue: publish.yml fails
Solution: verify the pypi environment and trusted publisher configuration, then rerun the
workflow.
Issue: Package not installable immediately
Solution: wait a few minutes for PyPI indexing/CDN propagation, then retry verification.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 1 of the 12 instructions most ship operate skills give in ~1.5k tokens
Counted across 779 of the 1,178 authors here whose files we hold, read 2026-08-07
- Document a rollback plan before deploymentin 41 of 779, across 22 files
- Update the changelogin 21 of 779, across 19 files
- Run the test suitein 20 of 779
- Create an annotated git tagin 20 of 779
- Clean up feature flags after full rolloutin 18 of 779, across 10 files
- Verify deployment health after launchin 18 of 779, across 10 files
- Test both feature flag statesin 17 of 779, across 9 files
- Verify the working tree is cleanhere, and in 17 of 779
- Make database migrations backward-compatiblein 16 of 779, across 8 files
- Set up error monitoring before launchin 15 of 779, across 7 files
- Monitor metrics at each rollout stagein 14 of 779, across 5 files
- Create a GitHub releasein 14 of 779
Said here and by no other author read
- update root package version
- commit and push release preparation
- build root package successfully
- verify GitHub Release workflow
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.