Grounds Python work in the official PEP index at https://peps.python.org/ (start from PEP 0): style and docstrings (PEP 8, PEP 257), typing (PEP 484 and related typing PEPs, PEP 561 for distributed types), builds and metadata (PEP 517, 518, 621, 660), versions (PEP 440), clearer failures (PEP 678), plus planning through release. Use whenever someone designs or implements Python libraries or applications, edits pyproject.toml, sets up Ruff/mypy/pytest in CI, prepares sdists/wheels or a PyPI release, adds or fixes py.typed, migrates off setup.py, settles “what does the PEP say?” debates, or wants PEP-compliant, PyPA-aligned, or standards-based Python. Do not use for non-Python stacks, front-end-only or infra-only work, or questions that never need peps.python.org.
Treat published PEPs as the source of truth for standards they define. The canonical index is PEP 0 — Index of Python Enhancement Proposals. Read the specific PEP (or topic index: Packaging, Typing, Release, Governance) before overriding team habit, blog posts, or old examples.
If guidance conflicts, prefer the active PEP text on peps.python.org and note deprecations or superseded PEPs in the index.
Machine-readable metadata for all PEPs: see API on PEP 0 (https://peps.python.org/ → API / JSON).
Use this flow; details and links live in references/pep-lifecycle-map.md.
| Phase | Goal | Start here (examples) |
|---|---|---|
| Plan | Problem shape, public API, compatibility story | PEP 20 (design ethos); domain PEPs from index (e.g. typing, packaging topics) |
| Develop | Readable, consistent code and APIs | PEP 8, PEP 257; typing: PEP 484 and follow-ups in Typing topic |
| Verify | Correctness and regressions | Tests + type-checking where PEP 484/561 apply; PEP 678 (exception notes) when enriching failures |
| Integrate | Reproducible builds and dependencies | PEP 517 / 518 / 621; PEP 660 (editable installs) |
| Release | Identifiers and artifacts users can trust | PEP 440 (versioning); packaging PEPs from index; PEP 561 for type information distribution |
When the task touches only one area (e.g. “fix docstrings”), still verify against the listed PEP rather than memory.
pyproject.toml per PEP 621 where applicable; build backends per PEP 517/518.--root). It runs safe checks (compileall, optional ruff, mypy, pytest when available). Fix failures; do not silence checks to “match PEP” without reading the relevant PEP.Run the bundled validator from your project root (adjust path if the skill lives elsewhere, e.g. under skills/python-pep-lifecycle/ in this repository or ~/.cursor/skills/python-pep-lifecycle/ after install):
python path/to/python-pep-lifecycle/scripts/validate_python_project.py --root .
# Strict: fail if ruff, mypy, or pytest is missing or reports errors
python path/to/python-pep-lifecycle/scripts/validate_python_project.py --root . --require ruff,mypy,pytest
For an expanded PEP-by-phase table and topic links, read references/pep-lifecycle-map.md.