python-pep-author について
Python コミュニティの提案を、形式と手順に沿った PEP 草案にまとめるスキルです。草案の生成・検査スクリプトと、提案種別、セクション、レビュー手順の資料を備えています。
主な機能
- 01PEP の種別と手順の案内
- 02PEP 草案の生成スクリプト
- 03草案の検査スクリプト
- 04ヘッダー項目とセクションの資料
- 05提出・レビュー手順の案内
活用シーン
- 01Python の提案を PEP として構成
- 02正しいヘッダー付き草案の生成
- 03必須項目とセクションの確認
- 04コミュニティ提出用草案の準備
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ pproenca/ dot-skills --skill python-pep-authorインストール後、Claude Code で/python-pep-authorを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
gotchas.mdmetadata.jsonassets/templates/pep-template.rstreferences/header-fields.mdpep-types.mdsections.mdstatus-lifecycle.mdworkflow.mdscripts/check-pep.shnew-pep.sh詳細
Python 拡張提案(PEP)を書く
PEP は、Python コミュニティが新しい言語機能、標準ライブラリの変更、相互運用性標準、またはプロセスや情報提供に関するガイドラインを提案するために使う設計文書です。このスキルは、アイデアの段階から、python/peps リポジトリに提出できる、書式が正しくプロセスに準拠したドラフトの作成まで、執筆者を支援します。
PEP の難しい点は文章そのものではありません。適切な種別を選び、ヘッダーの前文を正しく整え、採択基準を満たすセクションをすべて揃え、プロセス(事前確認、スポンサー、レビュー)に従うことです。このスキルには、決定論的な作業を行う 2 つのスクリプトと、判断が必要な箇所を確認するための参考資料が含まれています。
適用する場面
- ユーザーが PEP の執筆/ドラフト作成/構成や「Python 拡張提案」を依頼した場合。
- ユーザーが Python 言語または標準ライブラリの機能を提案したいと考え、正式な文書としてまとめる必要がある場合。
- ユーザーが Python Discourse で議論してきたアイデアを PEP のドラフトにまとめたい場合。
- ユーザーが PEP のテンプレート、ヘッダーフィールド、またはセクション構成について説明や生成を求めている場合。
- ユーザーが 既存の PEP を改訂している場合(ステータスの変更、Resolution の追加、レビューのフィードバックへの対応など)。
社内向けの RFC や設計文書にはこのスキルを使用しないでください(dev-rfc を使用してください)。PEP は、PEP 1 によって管理される、CPython/Python コミュニティ上流向けの提案です。
前提条件
- 2 つのスクリプトを実行するための Bash と coreutils(
awk、sed、grep、date)。macOS/Linux には通常、最初から含まれています。 - github.com/python/peps のクローンまたはフォーク。提出する準備が整ったとき(ステップ 6)にのみ必要です。ドラフトの作成にはリポジトリは不要です。
- ドラフト作成や lint には Python ランタイムは不要です。参照実装がある場合、それは執筆者が別途管理するコードベースにあります。
ワークフローの概要
1. Vet the idea ────► 2. Choose the type ────► 3. Scaffold the file
(is it PEP-able?) (Standards/Info/Process) (scripts/new-pep.sh)
│
6. Submit ◄──── 5. Self-check ◄──── 4. Draft each section
(sponsor, PR) (scripts/check-pep.sh) (to the acceptance bar)
│
▼
7. Review & resolution ──► update Status + Resolution header
1. アイデアを事前確認する(執筆を始める前に)
過去の提案と重複していたり、コミュニティ全体に関わる範囲でなかったりする PEP は、すぐに却下されます。まず、アイデアを Python Discourse の Ideas カテゴリーに投稿してください(専門分野の内容なら Typing または Packaging カテゴリーに投稿してください)。独自性があり、コミュニティ全体に適用でき、過去の議論ですでに決着していないことを確認します。投稿先や確認事項については、references/workflow.md を参照してください。
2. PEP の種別を選ぶ
種別は Standards Track、Informational、Process の 3 つです。種別によって必須ヘッダー(例:Python-Version、Resolution)と採択基準が決まります。references/pep-types.md を参照して選択してください。
3. ファイルのひな形を作成する
前文のフィールドと順序は厳密に決まっているため、手入力ではなく、正しいヘッダーを備えた有効な reStructuredText ファイルを生成します。
scripts/new-pep.sh \
--title "A short descriptive title" \
--author "Random J. User <[email protected]>" \
--type "Standards Track" \
--python-version 3.15 # Standards Track only; omit otherwise
これにより pep-9999.rst(9999 は仮の番号で、実際の番号は PEP 編集者が割り当てます)が作成され、Status: Draft と今日の日付の Created が設定され、タイトルが 44 文字以内であることが確認されます。使い方の詳細は、引数なしで scripts/new-pep.sh を実行してください。
4. 各セクションのドラフトを書く
本文のセクションは、PEP 12 で定められた標準の順序に沿って記入します:Abstract → Motivation → Specification → Rationale → Backwards Compatibility → Security Implications → How to Teach This → Reference Implementation → Rejected Ideas → Open Issues → Acknowledgements → Footnotes → Change History → Copyright。 各セクションには固有の役割と品質基準があります。ドラフトを書く前に references/sections.md を読み、記入するヘッダーがある場合は references/header-fields.md(Sponsor、Discussions-To、Requires など)を参照してください。
PEP 1 に基づく採択基準では、提案は明確かつ完全な説明であり、全体として改善となり、インタープリターを不当に複雑化させない堅実な実装を備え、**「Python らしい」**ものである必要があります。この基準を満たすように書いてください。
5. 下書きをセルフチェックする
誰かに見せる前に、ヘッダーと必須構成を lint します。
scripts/check-pep.sh pep-9999.rst
必須ヘッダーの有無、タイトルの長さ、有効な Status/Type の値、Created の日付形式、必須の CC0 著作権表示、Abstract セクションを検証し、PASS/WARN/FAIL を報告します。FAIL がある場合は、ゼロ以外の終了コードで終了します。
すべての FAIL を修正してください。
6. 提出する
共著者に CPython コア開発者がいない場合、まずスポンサー(PEP を主導するコア開発者)を見つける必要があります。次に python/peps をフォークし、pep-NNNN.rst を追加して、.github/CODEOWNERS に著者とスポンサーを記載し、プルリクエストを作成します。PEP 編集者が形式と妥当性を確認し、番号を割り当てます。詳しい手順と役割の定義については、references/workflow.md を参照してください。
7. レビューと決定
著者(およびスポンサー)が準備完了と判断したら、内容のレビューと採否の決定はSteering Council(または任命された PEP-Delegate)が行います。決定後、Status を更新し、決定文へのリンクを含む Resolution ヘッダーを追加してください。ステータスの全ライフサイクルと有効な遷移については、references/status-lifecycle.md を参照してください。
参考ファイル
| ファイル | 読むタイミング |
|---|---|
| references/workflow.md | 審査、スポンサー探し、提出、レビュープロセス、役割、所有権の移管 |
| references/pep-types.md | Standards Track/Informational/Process の選択 |
| references/header-fields.md | 前文の各フィールドの記入 — 書式、必須か任意か、例 |
| references/status-lifecycle.md | Status の設定や変更、有効な遷移、Resolution ヘッダーの理解 |
| references/sections.md | 本文の作成 — 各セクションに含める内容、RST の規約、採択基準 |
スクリプト
| スクリプト | 機能 |
|---|---|
scripts/new-pep.sh | テンプレートから有効な pep-NNNN.rst のひな形を作成し、ヘッダーフィールドを置換して、タイトルの長さ制限を適用します |
scripts/check-pep.sh | PEP 1/PEP 12 の規則(ヘッダー、ステータス/種類、日付形式、著作権、要約)に照らして PEP の下書きを lint します |
スクリプトが使用するテンプレートは assets/templates/pep-template.rst にあります。ヘッダーを手入力する場合は、そのままコピーしてください。
注意点
gotchas.md を参照してください。初期段階でよくある間違いは、Discourse での事前審査を省略すること、本当は Process PEP であるものに Standards Track を選ぶこと、必須の CC0 著作権表示を省くこと、タイトルが 44 文字を超えることです。
関連スキル
dev-rfc— 社内/企業の RFC、設計文書、アーキテクチャ文書(Python の上流提案ではありません)。