Update Dependencies
alorence/django-modern-rpc
Routine update of all project dependencies — uv itself, uv.lock (all groups), tool versions pinned in GitHub workflows and .pre-commit-config.yaml (uv, ruff, mypy...), and SHA-pinned GitHub Actions.
End-to-end skill for building, testing, linting, versioning, and publishing a production-grade Python library to PyPI.
$ npx skills add github/awesome-copilot --skill python-pypi-package-builder -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install github/awesome-copilot python-pypi-package-builder --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/github/awesome-copilot.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/python-pypi-package-builder .claude/skills/python-pypi-package-builder && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "python-pypi-package-builder" agent skill from https://github.com/github/awesome-copilot/tree/main/skills/python-pypi-package-builder into .claude/skills/python-pypi-package-builder/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "python-pypi-package-builder", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/github/awesome-copilot/tree/main/skills/python-pypi-package-builderType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add github/awesome-copilot --skill python-pypi-package-builder -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install github/awesome-copilot python-pypi-package-builder --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/github/awesome-copilot.git skills-src && mkdir -p .agents/skills && cp -r skills-src/skills/python-pypi-package-builder .agents/skills/python-pypi-package-builder && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "python-pypi-package-builder" agent skill from https://github.com/github/awesome-copilot/tree/main/skills/python-pypi-package-builder into .agents/skills/python-pypi-package-builder/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "python-pypi-package-builder", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add github/awesome-copilot --skill python-pypi-package-builder -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install github/awesome-copilot python-pypi-package-builder --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/github/awesome-copilot.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/skills/python-pypi-package-builder .cursor/skills/python-pypi-package-builder && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "python-pypi-package-builder" agent skill from https://github.com/github/awesome-copilot/tree/main/skills/python-pypi-package-builder into .cursor/skills/python-pypi-package-builder/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "python-pypi-package-builder", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/github/awesome-copilot.git --path skills/python-pypi-package-builder--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add github/awesome-copilot --skill python-pypi-package-builder -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install github/awesome-copilot python-pypi-package-builder --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/github/awesome-copilot.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/skills/python-pypi-package-builder .gemini/skills/python-pypi-package-builder && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "python-pypi-package-builder" agent skill from https://github.com/github/awesome-copilot/tree/main/skills/python-pypi-package-builder into .gemini/skills/python-pypi-package-builder/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "python-pypi-package-builder", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install github/awesome-copilot python-pypi-package-builderInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add github/awesome-copilot --skill python-pypi-package-builder -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/github/awesome-copilot.git skills-src && mkdir -p .github/skills && cp -r skills-src/skills/python-pypi-package-builder .github/skills/python-pypi-package-builder && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "python-pypi-package-builder" agent skill from https://github.com/github/awesome-copilot/tree/main/skills/python-pypi-package-builder into .github/skills/python-pypi-package-builder/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "python-pypi-package-builder", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add github/awesome-copilot --skill python-pypi-package-builder -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install github/awesome-copilot python-pypi-package-builder --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/github/awesome-copilot.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/skills/python-pypi-package-builder .opencode/skills/python-pypi-package-builder && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "python-pypi-package-builder" agent skill from https://github.com/github/awesome-copilot/tree/main/skills/python-pypi-package-builder into .opencode/skills/python-pypi-package-builder/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "python-pypi-package-builder", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
python-pypi-package-builderEnd-to-end skill for building, testing, linting, versioning, and publishing a production-grade Python library to PyPI.
Python Pypi Package Builder is an agent skill from github/awesome-copilot, published by the product's own GitHub organization. End-to-end skill for building, testing, linting, versioning, and publishing a production-grade Python library to PyPI. Covers all four build backends (setuptools+setuptoolsscm, hatchling, flit, poetry), PEP 440 versioning, semantic versioning, dynamic git-tag versioning, OOP/SOLID design, type hints (PEP 484/526/544/561), Trusted Publishing (OIDC), and the full PyPA packaging flow. Use for: creating Python packages, pip-installable SDKs, CLI tools, framework plugins, pyproject.toml setup, py.typed, setuptoolsscm…
Its SKILL.md is about 4.6k tokens, which your agent loads only when the skill is triggered. The skill folder holds 12 other files, including scripts and reference files (for example `references/architecture-patterns.md`, `references/ci-publishing.md` and `references/community-docs.md`).
It sits in Development, covering Type safety, CI/CD and Linting and formatting. It works with Python, Git and GitHub Actions. The repository describes itself as: Community-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot. The licence is MIT.
7 steps, taken from the step headings in SKILL.md.
Read from SKILL.md and the folder at commit 727ff2e. It shows what the files ask for, not the result of running them.
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Ships 1 file in scripts/ (Python), which the agent can run.
Shell commands in SKILL.md call:
gitpippythonFrom the folder's file list and the shell code blocks in SKILL.md.
Hosts in commands or code, which the agent is likely to contact:
pypi.orgtest.pypi.orgFrom URLs in SKILL.md, links to its own repository left out.
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Python Pypi Package Builder loads about 4.6k tokens when it runs, and up to ~31k if it reads all its reference files. Until then it costs about 154 tokens; SKILL.md has 1,244 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.
The full file from github/awesome-copilot at commit 727ff2e, republished under its MIT licence (© github). 1,244 words, ~4,610 tokens.
.claude/skills/python-pypi-package-builder/SKILL.md (or your agent's skills folder). This skill also uses 10 other files; get the full folder from GitHub.A complete, battle-tested guide for building, testing, linting, versioning, typing, and publishing a production-grade Python library to PyPI — from first commit to community-ready release.
AI Agent Instruction: Read this entire file before writing a single line of code or creating any file. Every decision — layout, backend, versioning strategy, patterns, CI — has a decision rule here. Follow the decision trees in order. This skill applies to any Python package type (utility, SDK, CLI, plugin, data library). Do not skip sections.
| Section in this file | What it covers |
|---|---|
| 1. Skill Trigger | When to load this skill |
| 2. Package Type Decision | Identify what you are building |
| 3. Folder Structure Decision | src/ vs flat vs monorepo |
| 4. Build Backend Decision | setuptools / hatchling / flit / poetry |
| 5. PyPA Packaging Flow | The canonical publish pipeline |
| 6. Project Structure Templates | Full layouts for every option |
| 7. Versioning Strategy | PEP 440, semver, dynamic vs static |
| Reference file | What it covers |
|---|---|
references/pyproject-toml.md | All four backend templates, setuptools_scm, py.typed, tool configs |
references/library-patterns.md | OOP/SOLID, type hints, core class design, factory, protocols, CLI |
references/testing-quality.md | conftest.py, unit/backend/async tests, ruff/mypy/pre-commit |
references/ci-publishing.md | ci.yml, publish.yml, Trusted Publishing, TestPyPI, CHANGELOG, release checklist |
references/community-docs.md | README, docstrings, CONTRIBUTING, SECURITY, anti-patterns, master checklist |
references/architecture-patterns.md | Backend system (plugin/strategy), config layer, transport layer, CLI, backend injection |
references/versioning-strategy.md | PEP 440, SemVer, pre-release, setuptools_scm deep-dive, flit static, decision engine |
references/release-governance.md | Branch strategy, branch protection, OIDC, tag author validation, prevent invalid tags |
references/tooling-ruff.md | Ruff-only setup (replaces black/isort), mypy config, pre-commit, asyncio_mode=auto |
Scaffold script: run python skills/python-pypi-package-builder/scripts/scaffold.py --name your-package-name
to generate the entire directory layout, stub files, and pyproject.toml in one command.
Load this skill whenever the user wants to:
pyproject.toml, linting, mypy, pre-commit, or GitHub Actions for a Python projectsetuptools_scm, PEP 440, semver, static versioning)py.typed, MANIFEST.in, RECORD, classifiersAlso trigger for phrases like: "build a Python SDK", "publish my library", "set up PyPI CI", "create a pip package", "how do I publish to PyPI", "pyproject.toml help", "PEP 561 typed", "setuptools_scm version", "semver Python", "PEP 440", "git tag release", "Trusted Publishing".
Identify what the user is building before writing any code. Each type has distinct patterns.
| Type | Core Pattern | Entry Point | Key Deps | Example Packages |
|---|---|---|---|---|
| Utility library | Module of pure functions + helpers | Import API only | Minimal | arrow, humanize, boltons, more-itertools |
| API client / SDK | Class with methods, auth, retry logic | Import API only | httpx or requests | boto3, stripe-python, openai |
| CLI tool | Command functions + argument parser | [project.scripts] or [project.entry-points] | click or typer | black, ruff, httpie, rich |
| Framework plugin | Plugin class, hook registration | [project.entry-points."framework.plugin"] | Framework dep | pytest-*, django-*, flask-* |
| Data processing library | Classes + functional pipeline | Import API only | Optional: numpy, pandas | pydantic, marshmallow, cerberus |
| Mixed / generic | Combination of above | Varies | Varies | Many real-world packages |
Decision Rule: Ask the user if unclear. A package can combine types (e.g., SDK with a CLI entry point) — use the primary type for structural decisions and add secondary type patterns on top.
For implementation patterns of each type, see references/library-patterns.md.
my-python-librarymy_python_librarypip install <name> fails first)Does the package have 5+ internal modules OR multiple contributors OR complex sub-packages?
├── YES → Use src/ layout
│ Reason: prevents accidental import of uninstalled code during development;
│ separates source from project root files; PyPA-recommended for large projects.
│
├── NO → Is it a single-module, focused package (e.g., one file + helpers)?
│ ├── YES → Use flat layout
│ └── NO (medium complexity) → Use flat layout, migrate to src/ if it grows
│
└── Is it multiple related packages under one namespace (e.g., myorg.http, myorg.db)?
└── YES → Use namespace/monorepo layout| Situation | Use |
|---|---|
| New project, unknown future size | src/ layout (safest default) |
| Single-purpose, 1–4 modules | Flat layout |
| Large library, many contributors | src/ layout |
| Multiple packages in one repo | Namespace / monorepo |
| Migrating old flat project | Keep flat; migrate to src/ at next major version |
Does the user need version derived automatically from git tags?
├── YES → Use setuptools + setuptools_scm
│ (git tag v1.0.0 → that IS your release workflow)
│
└── NO → Does the user want an all-in-one tool (deps + build + publish)?
├── YES → Use poetry (v2+ supports standard [project] table)
│
└── NO → Is the package pure Python with no C extensions?
├── YES, minimal config preferred → Use flit
│ (zero config, auto-discovers version from __version__)
│
└── YES, modern & fast preferred → Use hatchling
(zero-config, plugin system, no setup.py needed)
Does the package have C/Cython/Fortran extensions?
└── YES → MUST use setuptools (only backend with full native extension support)| Backend | Version source | Config | C extensions | Best for |
|---|---|---|---|---|
setuptools + setuptools_scm | git tags (automatic) | pyproject.toml + optional setup.py shim | Yes | Projects with git-tag releases; any complexity |
hatchling | manual or plugin | pyproject.toml only | No | New pure-Python projects; fast, modern |
flit | __version__ in __init__.py | pyproject.toml only | No | Very simple, single-module packages |
poetry | pyproject.toml field | pyproject.toml only | No | Teams wanting integrated dep management |
For all four complete pyproject.toml templates, see references/pyproject-toml.md.
This is the canonical end-to-end flow from source code to user install. Every step must be understood before publishing.
1. SOURCE TREE
Your code in version control (git)
└── pyproject.toml describes metadata + build system
2. BUILD
python -m build
└── Produces two artifacts in dist/:
├── *.tar.gz → source distribution (sdist)
└── *.whl → built distribution (wheel) — preferred by pip
3. VALIDATE
twine check dist/*
└── Checks metadata, README rendering, and PyPI compatibility
4. TEST PUBLISH (first release only)
twine upload --repository testpypi dist/*
└── Verify: pip install --index-url https://test.pypi.org/simple/ your-package
5. PUBLISH
twine upload dist/* ← manual fallback
OR GitHub Actions publish.yml ← recommended (Trusted Publishing / OIDC)
6. USER INSTALL
pip install your-package
pip install "your-package[extra]"| Concept | What it means |
|---|---|
| sdist | Source distribution — your source + metadata; used when no wheel is available |
| wheel (.whl) | Pre-built binary — pip extracts directly into site-packages; no build step |
| PEP 517/518 | Standard build system interface via pyproject.toml [build-system] table |
| PEP 621 | Standard [project] table in pyproject.toml; all modern backends support it |
| PEP 639 | license key as SPDX string (e.g., "MIT", "Apache-2.0") — not {text = "MIT"} |
| PEP 561 | py.typed empty marker file — tells mypy/IDEs this package ships type information |
For complete CI workflow and publishing setup, see references/ci-publishing.md.
your-package/
├── src/
│ └── your_package/
│ ├── __init__.py # Public API: __all__, __version__
│ ├── py.typed # PEP 561 marker — EMPTY FILE
│ ├── core.py # Primary implementation
│ ├── client.py # (API client type) or remove
│ ├── cli.py # (CLI type) click/typer commands, or remove
│ ├── config.py # Settings / configuration dataclass
│ ├── exceptions.py # Custom exception hierarchy
│ ├── models.py # Data classes, Pydantic models, TypedDicts
│ ├── utils.py # Internal helpers (prefix _utils if private)
│ ├── types.py # Shared type aliases and TypeVars
│ └── backends/ # (Plugin pattern) — remove if not needed
│ ├── __init__.py # Protocol / ABC interface definition
│ ├── memory.py # Default zero-dep implementation
│ └── redis.py # Optional heavy implementation
├── tests/
│ ├── __init__.py
│ ├── conftest.py # Shared fixtures
│ ├── unit/
│ │ ├── __init__.py
│ │ ├── test_core.py
│ │ ├── test_config.py
│ │ └── test_models.py
│ ├── integration/
│ │ ├── __init__.py
│ │ └── test_backends.py
│ └── e2e/ # Optional: end-to-end tests
│ └── __init__.py
├── docs/ # Optional: mkdocs or sphinx
├── scripts/
│ └── scaffold.py
├── .github/
│ ├── workflows/
│ │ ├── ci.yml
│ │ └── publish.yml
│ └── ISSUE_TEMPLATE/
│ ├── bug_report.md
│ └── feature_request.md
├── .pre-commit-config.yaml
├── pyproject.toml
├── CHANGELOG.md
├── CONTRIBUTING.md
├── SECURITY.md
├── LICENSE
├── README.md
└── .gitignoreyour-package/
├── your_package/ # ← at root, not inside src/
│ ├── __init__.py
│ ├── py.typed
│ └── ... (same internal structure)
├── tests/
└── ... (same top-level files)your-org/
├── packages/
│ ├── your-org-core/
│ │ ├── src/your_org/core/
│ │ └── pyproject.toml
│ ├── your-org-http/
│ │ ├── src/your_org/http/
│ │ └── pyproject.toml
│ └── your-org-cli/
│ ├── src/your_org/cli/
│ └── pyproject.toml
├── .github/workflows/
└── README.mdEach sub-package has its own pyproject.toml. They share the your_org namespace via PEP 420
implicit namespace packages (no __init__.py in the namespace root).
| File | Purpose | When to include |
|---|---|---|
__init__.py | Public API surface; re-exports; __version__ | Always |
py.typed | PEP 561 typed-package marker (empty) | Always |
core.py | Primary class / main logic | Always |
config.py | Settings dataclass or Pydantic model | When configurable |
exceptions.py | Exception hierarchy (YourBaseError → specifics) | Always |
models.py | Data models / DTOs / TypedDicts | When data-heavy |
utils.py | Internal helpers (not part of public API) | As needed |
types.py | Shared TypeVar, TypeAlias, Protocol definitions | When complex typing |
cli.py | CLI entry points (click/typer) | CLI type only |
backends/ | Plugin/strategy pattern | When swappable implementations |
_compat.py | Python version compatibility shims | When 3.9–3.13 compat needed |
Canonical form: N[.N]+[{a|b|rc}N][.postN][.devN]
Examples:
1.0.0 Stable release
1.0.0a1 Alpha (pre-release)
1.0.0b2 Beta
1.0.0rc1 Release candidate
1.0.0.post1 Post-release (e.g., packaging fix only)
1.0.0.dev1 Development snapshot (not for PyPI)MAJOR.MINOR.PATCH
MAJOR: Breaking API change (remove/rename public function/class/arg)
MINOR: New feature, fully backward-compatible
PATCH: Bug fix, no API change# How it works:
git tag v1.0.0 → installed version = 1.0.0
git tag v1.1.0 → installed version = 1.1.0
(commits after tag) → version = 1.1.0.post1 (suffix stripped for PyPI)
# In code — NEVER hardcode when using setuptools_scm:
from importlib.metadata import version, PackageNotFoundError
try:
__version__ = version("your-package")
except PackageNotFoundError:
__version__ = "0.0.0-dev" # Fallback for uninstalled dev checkoutsRequired pyproject.toml config:
[tool.setuptools_scm]
version_scheme = "post-release"
local_scheme = "no-local-version" # Prevents +g<hash> from breaking PyPI uploadsCritical: always set fetch-depth: 0 in every CI checkout step. Without full git history,
setuptools_scm cannot find tags and the build version silently falls back to 0.0.0+dev.
# your_package/__init__.py
__version__ = "1.0.0" # Update this before every release# In [project] dependencies:
"httpx>=0.24" # Minimum version — PREFERRED for libraries
"httpx>=0.24,<1.0" # Upper bound only when a known breaking change exists
"httpx==0.27.0" # Pin exactly ONLY in applications, NOT libraries
# NEVER do this in a library — it breaks dependency resolution for users:
# "httpx~=0.24.0" # Too tight
# "httpx==0.27.*" # Fragile# 1. Update CHANGELOG.md — move [Unreleased] entries to [x.y.z] - YYYY-MM-DD
# 2. Commit the changelog
git add CHANGELOG.md
git commit -m "chore: prepare release vX.Y.Z"
# 3. Tag and push — this triggers publish.yml automatically
git tag vX.Y.Z
git push origin main --tags
# 4. Monitor GitHub Actions → verify on https://pypi.org/project/your-package/For complete pyproject.toml templates for all four backends, see references/pyproject-toml.md.
After understanding decisions and structure:
Set up pyproject.toml → references/pyproject-toml.md
All four backend templates (setuptools+scm, hatchling, flit, poetry), full tool configs,
py.typed setup, versioning config.
Write your library code → references/library-patterns.md
OOP/SOLID principles, type hints (PEP 484/526/544/561), core class design, factory functions,
__init__.py, plugin/backend pattern, CLI entry point.
Add tests and code quality → references/testing-quality.md
conftest.py, unit/backend/async tests, parametrize, ruff/mypy/pre-commit setup.
Set up CI/CD and publish → references/ci-publishing.md
ci.yml, publish.yml with Trusted Publishing (OIDC, no API tokens), CHANGELOG format,
release checklist.
Polish for community/OSS → references/community-docs.md
README sections, docstring format, CONTRIBUTING, SECURITY, issue templates, anti-patterns
table, and master release checklist.
Design backends, config, transport, CLI → references/architecture-patterns.md
Backend system (plugin/strategy pattern), Settings dataclass, HTTP transport layer,
CLI with click/typer, backend injection rules.
Choose and implement a versioning strategy → references/versioning-strategy.md
PEP 440 canonical forms, SemVer rules, pre-release identifiers, setuptools_scm deep-dive,
flit static versioning, decision engine (DEFAULT/BEGINNER/MINIMAL).
Govern releases and secure the publish pipeline → references/release-governance.md
Branch strategy, branch protection rules, OIDC Trusted Publishing setup, tag author
validation in CI, tag format enforcement, full governed publish.yml.
Simplify tooling with Ruff → references/tooling-ruff.md
Ruff-only setup replacing black/isort/flake8, mypy config, pre-commit hooks,
asyncio_mode=auto (remove @pytest.mark.asyncio), migration guide.
© github, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
SKILL.md and 10 other files (scripts, references) in skills/python-pypi-package-builder of github/awesome-copilot.
Open the folder on GitHubat commit 727ff2e
We found 1 copy of this SKILL.md (exact, near-identical or edited) in other folders, from 1 other GitHub owner. This page covers the copy in github/awesome-copilot, which our catalogue first saw on October 7, 2026.
Python Pypi Package Builder next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Python Pypi Package Builder this skillgithub/awesome-copilot | 40k | 1 repos | ~4.6k | Automated safety check: Pass | MIT | |
| Update Dependenciesalorence/django-modern-rpc | 111 | — | ~1.3k | Automated safety check: Pass | MIT | |
| Simple Modern Uvjlevy/simple-modern-uv | 301 | — | ~1.9k | Automated safety check: Pass | MIT | |
| Pypi ReleasealchemiststudiosDOTai/tunacode | 125 | — | ~2.2k | Automated safety check: Pass | MIT | |
| Obsidian Plugin Releasecrafter-station/skills | 111 | — | ~1.8k | Automated safety check: Pass | MIT | |
| Manor CI Triagemanor-os/manor-ai | 161 | — | ~533 | Automated safety check: Pass | Custom licence |
alorence/django-modern-rpc
Routine update of all project dependencies — uv itself, uv.lock (all groups), tool versions pinned in GitHub workflows and .pre-commit-config.yaml (uv, ruff, mypy...), and SHA-pinned GitHub Actions.
jlevy/simple-modern-uv
Start, selectively modernize, fully migrate, or update Python projects using simple-modern-uv practices: uv, ruff, BasedPyright, pytest, GitHub Actions CI, and tag-driven PyPI publishing.
alchemiststudiosDOTai/tunacode
This skill should be used when releasing tunacode-cli to PyPI.
crafter-station/skills
Release a new version of an Obsidian community plugin without forgetting steps.
manor-os/manor-ai
A skill your agent uses when Manor GitHub Actions, .github/workflows/ci.yml, OSS smoke/regression jobs, web source smoke, frontend build, lint, or public CI failure logs need diagnosis or repair.
spencerpauly/awesome-cursor-skills
Set up a GitHub Actions CI/CD pipeline with linting, testing, type-checking, and deployment steps.
github/awesome-copilot
Maps an unfamiliar codebase into seven evidence-backed documents in docs/codebase/, using a scan script and templates, for onboarding or architecture write-ups.
github/awesome-copilot
Designs Azure infrastructure from a natural-language description, or diagrams an existing resource group, then refines the design through conversation and deploys it with Bicep.
github/awesome-copilot
Generates, edits and validates draw.io files with correct mxGraph XML, covering flowcharts, architecture, sequence, ER and UML class diagrams.
github/awesome-copilot
Cleans raw credit data and screens variables before loan modeling, dropping unstable, noisy or redundant features and writing an Excel report of every step.
github/awesome-copilot
Builds a warm, browser-based daily focus board the user updates by talking to their agent, with Eisenhower priorities, a brain-dump box and kind not-today carryover.
github/awesome-copilot
Analyze Terraform plan JSON output for AzureRM Provider to distinguish between false-positive diffs (order-only changes in Set-type attributes) and actual resource changes.
Works with
Categories
End-to-end skill for building, testing, linting, versioning, and publishing a production-grade Python library to PyPI. Python Pypi Package Builder is an agent skill from github/awesome-copilot, published by the product's own GitHub organization. End-to-end skill for building, testing, linting, versioning, and publishing a production-grade Python library to PyPI.
Python Pypi Package Builder fits situations like: : creating Python packages; pip-installable SDKs; framework plugins; pyproject.toml setup.
Run `npx skills add github/awesome-copilot --skill python-pypi-package-builder -a claude-code`. Or copy the skill folder (skills/python-pypi-package-builder in github/awesome-copilot) into .claude/skills/python-pypi-package-builder in your project. Claude Code loads it when a task matches its description.
Run `npx skills add github/awesome-copilot --skill python-pypi-package-builder -a codex`. Or copy the skill folder (skills/python-pypi-package-builder in github/awesome-copilot) into .agents/skills/python-pypi-package-builder in your project. Codex loads it when a task matches its description.
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add github/awesome-copilot --skill python-pypi-package-builder -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/python-pypi-package-builder, .gemini/skills/python-pypi-package-builder, .github/skills/python-pypi-package-builder and .opencode/skills/python-pypi-package-builder in your project.
Going by SKILL.md and its folder, Python Pypi Package Builder needs Python for the scripts in its folder and the command-line tools its instructions call (git, pip and python). Our summary lists: Python 3.
SKILL.md names 2 domains. In commands or code: pypi.org and test.pypi.org; the agent is likely to contact these when it follows the instructions. This is read from the text; nothing was executed.
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.
Python Pypi Package Builder is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
About 4.6k tokens (SKILL.md is roughly 18k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 27k tokens, read only when the agent opens those files.
Skills that share tags, products or a category with Python Pypi Package Builder: Update Dependencies (alorence/django-modern-rpc, 111 stars), Simple Modern Uv (jlevy/simple-modern-uv, 301 stars), Pypi Release (alchemiststudiosDOTai/tunacode, 125 stars) and Obsidian Plugin Release (crafter-station/skills, 111 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
github (a GitHub organization, an official publisher) maintains it in github/awesome-copilot, which has 39,748 GitHub stars. The repository holds 417 skills in this directory. The repository was last updated on October 7, 2026.
Source: github/awesome-copilot on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.