Synthèse automatique
Configure et exécute automatiquement un workflow GitHub Actions pour publier des packages Python sur PyPI de manière sécurisée via OIDC, avec versionnage interactif PEP 440.
Points forts
- Intègre la validation de structure du projet avant la publication
- Propose un versionnage interactif conforme à PEP 440 (alpha, beta, RC, stable)
- Utilise l'authentification OIDC (Trusted Publishers) pour une sécurité renforcée
- Génère automatiquement le fichier de workflow GitHub Actions
Limites
- Nécessite un dépôt Git et GitHub Actions comme seule cible CI/CD
- Ne prend en charge que les packages Python avec pyproject.toml, setup.py ou setup.cfg
- Le versionnage interactif peut être rigide pour des versions personnalisées
Lorsque vous voulez automatiser et sécuriser la publication PyPI d'un package Python avec un workflow CI/CD et un bump de version interactif.
Si vous utilisez un autre système CI (Jenkins, GitLab CI, etc.) ou si vous préférez gérer les versions manuellement sans interaction.
Analyse de sécurité
SûrThe skill performs standard package publishing tasks using secure OIDC method. It uses git commands and Python invocations for validation and configuration, but no destructive or exfiltrating actions are instructed. The generated workflow pushes packages to PyPI via trusted publisher, which is safe.
Aucun point d'attention détecté
Comment cette analyse est faiteExemples
I want to publish my Python package to PyPI securely with automatic version bumping. Please use GitHub Actions and OIDC.Help me create a GitHub Actions workflow that publishes to PyPI using Trusted Publishers, with interactive version selection (alpha, beta, RC, stable).I need to publish a new release of my Python package. Guide me through version bumping and set up the PyPI publish workflow.name: secure-pypi-publish description: Complete workflow for publishing Python packages to PyPI securely using GitHub Actions and Trusted Publishers (OIDC). Includes interactive PEP 440 versioning, structure validation, and automatic workflow generation. allowed-tools: Bash(git:), Bash(python:), Read, Write, Edit, Question
Secure PyPI Publishing Workflow
You are a Python package publishing specialist. When the user activates this skill, execute the following sequential and interactive workflow:
Phase 1: Project Validation
1.1 Verify Git Environment
- Execute
git rev-parse --is-inside-work-treeto confirm you're in a Git repository - If not a Git repo, inform the user and halt the process
1.2 Detect Project Type
Search in order of preference:
pyproject.toml(recommended)setup.pysetup.cfg
Read the first file found and extract:
- Package name: Search in
[project.name],setup(name=...), or[metadata] name - Current version: Search in
[project.version],[tool.poetry.version],setup(version=...), or[metadata] version
1.3 Get Repository Information
- Execute
git remote get-url originto get the repo URL - Parse the URL to extract: owner/organization and repository name
- Validate that remote is configured correctly
1.4 Validate Minimum Structure
Verify that at least one exists:
- Source code directory (package name)
__init__.pyfile or Python modules
If validation fails, ask the user if they want to continue anyway.
Phase 2: Interactive Versioning (PEP 440)
2.1 Display Current Version
Present to the user:
Current version detected: X.Y.Z
Package name: your-package
Repository: owner/repo
2.2 Select Release Type
Use the question tool to ask:
Main question:
What kind of release is this?
Options:
Stable (e.g., 1.0.0)- Final release, production-readyAlpha (e.g., 1.0.0a1)- New features in development, unstable APIBeta (e.g., 1.0.0b1)- Feature complete, testing for bugsRelease Candidate (e.g., 1.0.0rc1)- Potential final version, final testing
2.3 For Pre-releases (Options 2-4)
If the user selects Alpha, Beta, or RC:
Ask for iteration number:
Enter the pre-release iteration number (default: 1):
- Validate it's a positive integer
- If empty, use 1
2.4 Calculate New Version
Apply PEP 440 rules:
For Stable:
- If current version is
1.2.3and user wants minor bump →1.3.0 - Ask which part to increment: major, minor, or patch
For Pre-releases:
- If current version is
1.2.3and user chooses Beta iteration 1 →1.2.3b1 - If pre-release already exists (e.g.,
1.2.3b1) and chooses Beta iteration 2 →1.2.3b2
PEP 440 Format:
- Alpha:
X.Y.ZaN(e.g.,1.0.0a1,2.3.4a2) - Beta:
X.Y.ZbN(e.g.,1.0.0b1,2.3.4b2) - Release Candidate:
X.Y.ZrcN(e.g.,1.0.0rc1,2.3.4rc3)
2.5 Confirm Version
Display:
New version will be: X.Y.Z[suffix]
Version breakdown:
- Base version: X.Y.Z
- Release type: [Stable|Alpha|Beta|Release Candidate]
- Pre-release iteration: N (if applicable)
Confirm this version? [y/N]
If not confirmed, return to step 2.2.
2.6 Update Configuration File
Modify the file detected in Phase 1:
pyproject.toml:
[project]
name = "your-package"
version = "X.Y.Zsuffix"
or if using Poetry:
[tool.poetry]
name = "your-package"
version = "X.Y.Zsuffix"
setup.py:
setup(
name="your-package",
version="X.Y.Zsuffix",
...
)
setup.cfg:
[metadata]
name = your-package
version = X.Y.Zsuffix
Use the Edit tool to make the precise change.
Phase 3: GitHub Actions Setup
3.1 Create Directory Structure
mkdir -p .github/workflows
3.2 Generate Workflow File
Create .github/workflows/pypi-publish.yml using the template from templates/pypi-publish.yml:
- Replace
{{PACKAGE_NAME}}with the package name - Workflow must use Trusted Publishers (OIDC) - DO NOT use API tokens
- Configure GitHub Environment:
pypi - Trigger: push tags with pattern
v*
3.3 Create/Update .gitignore (if necessary)
Verify if .gitignore exists and ensure it includes:
# Python
__pycache__/
*.py[cod]
*$py.class
dist/
build/
*.egg-info/
# Virtual environments
venv/
env/
.venv/
Phase 4: Final Instructions
Generate and display the following formatted output:
====================================================================
🎉 Your secure publishing flow (secure-pypi-publish) is ready!
====================================================================
To finish publishing version [X.Y.Zsuffix] of [package-name],
follow exactly these steps:
1️⃣ CONFIGURE TRUSTED PUBLISHER ON PYPI:
Go to: https://pypi.org/manage/account/publishing/
Click "Add a new pending publisher" and fill in:
- PyPI Project Name: [package-name]
- Owner: [owner]
- Repository name: [repo-name]
- Workflow name: pypi-publish.yml
- Environment name: pypi
Note: If the package already exists on PyPI, go to:
https://pypi.org/manage/project/[package-name]/publishing/
2️⃣ CREATE THE GITHUB ENVIRONMENT:
Go to: https://github.com/[owner]/[repo-name]/settings/environments/new
Create an environment named: pypi
(Optional) Add protection rules:
- Required reviewers for deployments
- Wait timer before deployments
- Deployment branches: main (or your default branch)
3️⃣ SAVE CHANGES IN GIT:
Run in your terminal:
git add .github/workflows/pypi-publish.yml [config-file]
git commit -m "chore: setup secure PyPI publishing for vX.Y.Zsuffix"
git push origin [default-branch]
4️⃣ CREATE THE TAG AND TRIGGER THE PIPELINE:
To trigger the publishing process, create a version tag and push it:
git tag -a vX.Y.Zsuffix -m "Release vX.Y.Zsuffix"
git push origin vX.Y.Zsuffix
👀 Track your publishing status at:
https://github.com/[owner]/[repo-name]/actions
📚 Documentation:
- PEP 440 Versioning: https://peps.python.org/pep-0440/
- Trusted Publishers: https://docs.pypi.org/trusted-publishers/
- GitHub Actions Environments: https://docs.github.com/en/actions/deployment/targeting-different-environments
💡 Tips:
- Test on TestPyPI first: Replace pypi.org with test.pypi.org in step 1
- Monitor the Actions run to catch any build errors
- Verify the package appears on PyPI after successful publish
====================================================================
Technical Notes
Parsing pyproject.toml
- Use simple regular expressions or manual parsing (avoid dependencies)
- Search for
[project]or[tool.poetry]section - Keep the rest of the file intact
Error Handling
- If configuration file cannot be parsed, show error and halt
- If current version doesn't comply with PEP 440, warn the user
- If remote is not configured, suggest
git remote add origin <url>
Optional Validations
- Check if package name already exists on PyPI (warning, not error)
- Check if there are uncommitted changes (ask if they want to continue)
Compatibility
- Support Python 3.8+
- Don't require external tools (only git and standard python)
- Work on Linux, macOS, and Windows
References
Du fichier au premier essai
Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.
Consulter la source et ses fichiers annexesCe téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.
1. Télécharger le fichier
Télécharger SKILL.mdDepuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/secure-pypi-publishing-workflow-mrzxup71/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.
Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.
mkdir -p '.skill-downloads/secure-pypi-publishing-workflow-mrzxup71' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/secure-pypi-publishing-workflow-mrzxup71/download' --output '.skill-downloads/secure-pypi-publishing-workflow-mrzxup71/SKILL.md.part' && mv '.skill-downloads/secure-pypi-publishing-workflow-mrzxup71/SKILL.md.part' '.skill-downloads/secure-pypi-publishing-workflow-mrzxup71/SKILL.md'2. Vérifier les prérequis
Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.
Outils déclarés par l’auteur (à vérifier dans votre agent) : Bash(git:*), Bash(python:*), Read, Write, Edit, Question
Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.
Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.
3. Charger la skill
Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.
Claude Code
test -f '.skill-downloads/secure-pypi-publishing-workflow-mrzxup71/SKILL.md' && test -s '.skill-downloads/secure-pypi-publishing-workflow-mrzxup71/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/secure-pypi-publish' && cp -R '.skill-downloads/secure-pypi-publishing-workflow-mrzxup71' '.claude/skills/secure-pypi-publish'OpenSkills
OpenSkills doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.
Installation officielle d’OpenSkillsopenskills install './.skill-downloads/secure-pypi-publishing-workflow-mrzxup71'openskills read 'secure-pypi-publishing-workflow-mrzxup71'La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.
Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.
openskills syncMode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.
4. Faire un premier essai
Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :
Lis .skill-downloads/secure-pypi-publishing-workflow-mrzxup71/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.
Configurer un canal de discussion avec SecretRefs
DevOps
Configurez des canaux de discussion avec des commandes non interactives, les secrets étant uniquement des SecretRefs. Couvre les étapes de collecte, modification, réparation et vérification.
Enquêter sur les échecs CI de ClickHouse
DevOps
Investigue un échec CI de ClickHouse de bout en bout à partir d'une URL de PR ou de rapport S3. Récupère les tests échoués, classe flaky vs vraie régression, et cherche des issues/fixes existants.
Revue de PR Ansible
DevOps
Examine une PR Ansible selon le processus standardisé du projet, incluant la validation des changelogs, la couverture de tests et le suivi des commentaires.