python-pep

name	python-pep
description	Write a Python Enhancement Proposal (PEP) — a formal design document proposing a change to the Python language, standard library, or process, with the canonical RFC822 header preamble plus Abstract, Motivation, Rationale, Specification, Backwards Compatibility, Security Implications, How to Teach This, Reference Implementation, Rejected Ideas, and Open Issues. Use when the user is proposing or drafting a Python language/stdlib/process change in PEP form. Anti-trigger; for a project's own architecture decision use an ADR skill, and for end-user task instructions use a how-to.
argument-hint	<the proposed Python change>

python-pep

Produces a Python Enhancement Proposal: the standardized design document the CPython community uses to propose and record changes. A PEP argues a change on its merits, specifies it precisely enough to implement, and survives review by the Steering Council or a delegate. It is not a tutorial, a changelog, or a bug report — it is a durable, reviewable design record.

The three PEP types

• Standards Track — a new feature or implementation change to Python (the language, the C API, or the standard library). Most PEPs are this type.
• Informational — design guidance, conventions, or community information that does not propose a new feature (e.g. the release schedule).
• Process — a change to a process around Python (decision-making, governance, tooling) rather than the language itself.

Status lifecycle

Draft ──> Accepted ──> Final
  │           │
  ├─> Rejected         (turned down on its merits)
  ├─> Withdrawn        (the author abandons it)
  ├─> Deferred         (no champion / not ready)
  └─> Superseded       (replaced by a later PEP)