Package Release
Skill0 starsChanged 7 months agoMITView on GitHub
Multi-persona workflow for releasing TTA.dev packages to PyPI with full quality validation
- Deletes or force-pushes
- Installs packages
- Commits and pushes
In this repository25 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- .cursor/rules/tta-dev.mdcCursor rule
- build-test-verifySkill
- core-conventionsSkill
- create-atomic-noteSkill
- create-pull-requestSkill
- git-commitSkill
- sdd-workflowSkill
- self-review-checklistSkill
- session-startSkill
- build-test-verifySkill
- core-conventionsSkill
- create-agentSkill
- create-atomic-noteSkill
- create-pull-requestSkill
- Feature DevelopmentSkill
- git-commitSkill
- Incident ResponseSkill
- sdd-workflowSkill
- self-review-checklistSkill
- session-startSkill
- ttadev-llmSkill
- ttadev-primitivesSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 3 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 76
Add the new section to CHANGELOG.md and review any pinned version references in active docs:
- Distinctive: line 134
Goal: create the release tag, let GitHub create the release, and optionally publish to PyPI.
- Distinctive: line 190
If a release goes bad:
- Very specific: line 194
Use the PyPI web UI for the ttadev project to yank the bad release if necessary.
- Very specific: line 221
Solution: verify the pypi environment and trusted publisher configuration, then rerun the workflow.
- Distinctive: line 226
Solution: wait a few minutes for PyPI indexing/CDN propagation, then retry verification.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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.ymlStage 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
fiChoose:
- 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.tomlStep 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 || trueStep 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 mainHandoff: @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.shStep 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 distStep 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 -5Step 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.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

