mcpField
P
python-practice

python-practice

github.com/nrayyagari開発089 回インストール27 週間前に更新
リポジトリ

python-practice について

演習の作成に加え、デバッグ、コードレビュー、プロジェクト形式の練習を支援する Python 学習スキルです。Python の基礎からバックエンド、CLI、テスト、自動化まで実践力を伸ばしたい学習者向けです。

主な機能

  1. 01複数モードで演習を作成
  2. 02学習状況に応じて内容を調整
  3. 03バックエンドと自動化を扱う
  4. 04テストで演習を検証
  5. 05解答をレビューし学習ログを更新

活用シーン

  1. 01Python の基礎を練習
  2. 02Python 演習のデバッグ
  3. 03バックエンドや AWS 自動化の準備
  4. 04演習の解答をレビュー

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/nrayyagari/python-practice-skill --skill python-practice

インストール後、Claude Code で/python-practiceを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

README.md
.gitignore
evals/
prompts.md
references/
python-learning-guide.md
review-guide.md
learning-log.md
topic-catalog.md
practice-tracks.md
adaptive-learning.md
exercise-templates.md

詳細

Python Practice — 実践的な習熟

まず Python 言語を実践で使いこなす力を身につけ、その後、バックエンド、CLI、自動化、AWS ワークフロー、テスト、本番環境を意識したプロジェクトに応用する練習問題を生成します。

中心となるのは、Python で役立つものを作れるだけの習熟度を身につけることです。FastAPI、Flask、AWS の自動化は、カリキュラム全体ではなく、優先的に取り組む応用分野です。

通常の練習リクエストでは、トピックに応じて、独立した .py ファイルまたは小規模な Python パッケージとして3 つの練習問題を作成します。ルートの学習ログを参考に、役立つ練習内容を選んでください。ただし、進捗トラッカーを実行したり、非公開の進捗データベースを維持したりしないでください。

ユーザーが取り組む練習問題はすべて、次の固定リポジトリに配置します。

/home/laborant/repos/python-practice

ユーザーが別のパスを明示的に指定しない限り、Python の練習問題を別の場所に作成しないでください。

使用する場面

  • ユーザーが Python の練習、演習、チャレンジ、コードレビュー、デバッグを求めている場合。
  • ユーザーが関数、クラス、型ヒント、pytest、ファイル、JSON、HTTP、CLI、API、FastAPI、Flask、boto3、AWS の自動化、バックエンド開発、スクリプトについて尋ねている場合。
  • ユーザーがバックエンド向けの Python 学習、自動化スキル、AWS スクリプト作成、オープンソースの Python プロジェクトへの貢献準備を求めている場合。
  • ユーザーが「行き詰まりました」「解答をレビューしてください」「もっと難しく/簡単にしてください」と言ったり、Python の練習問題に取り組む中で確認の質問をしたりする場合。

ワークフロー

ステップ 1:トピックが指定されていない場合は尋ねる

ユーザーがトピックを指定していない場合は、次のメニューを提示します。

Which Python area do you want to practice?

1. Foundations       — syntax, functions, data structures, files, exceptions
2. OOP + Design      — classes, dataclasses, protocols, composition, package boundaries
3. Standard Library  — pathlib, json, csv, datetime, collections, itertools, logging, argparse
4. Testing + Quality — pytest, fixtures, mocks, typing, lint-friendly design
5. Backend Python    — HTTP, FastAPI, Flask, validation, middleware, service boundaries
6. Automation + AWS  — boto3-shaped clients, retries, pagination, IAM-safe scripts, CLIs
7. Data + Utilities  — pandas-style data handling, CSV/JSON transforms, reporting scripts

Pick one, or name a specific thing like "FastAPI dependencies" or "boto3 pagination".

ユーザーが直接トピックを指定した場合は、このステップを省略します。

ステップ 2:学習モードを選ぶ

ユーザーがモードを指定していない場合は、batch を使用します。

モード:

  • batch:練習問題を 3 つ出します。継続的な練習の標準モードです。
  • drill:1 つの概念または繰り返し起きる間違いに集中する、小規模な課題を 1 つ出します。
  • debug:本番環境を意識した、テスト付きの壊れたコードを扱います。
  • applied:現実的なバックエンド、CLI、AWS、または自動化の課題に取り組みます。
  • pr-simulation:小さな既存パッケージを読み、バグを修正し、トレードオフを説明します。
  • design-review:コーディングの前に、パッケージの境界、型、依存関係、エラーの扱いを決めます。
  • capstone:キャップストーンの段階的な課題に沿って、複数のステップから成るプロジェクトに取り組みます。

モードに応じて範囲を調整してください。小規模なドリル、レビュー、またはプロジェクト形式の課題を求められた場合は、無理に練習問題を 3 つ出さないでください。

ステップ 3:練習用ワークスペースを準備する

練習用リポジトリとして /home/laborant/repos/python-practice を使用します。

存在しない場合は、次のファイルを含む git リポジトリとして作成します。

  • README.md
  • learning-log.md
  • .gitignore

練習問題を作成する場合は、そのリポジトリ内の日付フォルダーに配置します。フォルダー名には次の形式を使用します。

D-mmm-YY

例:

  • 3-may-26
  • 30-apr-26
  • 12-jun-26

英語の月名の略称は、小文字で使用します:jan、feb、mar、apr、may、 jun、jul、aug、sep、oct、nov、dec。

ルール:

  • 新しい日には、その日付のフォルダーを作成します。
  • ユーザーが同じ日に練習問題の追加を求めた場合は、同じフォルダーに追加します。
  • そのフォルダーにすでにある練習問題の続きの番号を、新しい練習問題に付けます。
  • 日をまたいで参照できるように、ルートの learning-log.md を維持します。
  • 学習ログに記載されている場合を中心に、必要に応じて以前の日付のフォルダーを確認します。
  • ユーザーから依頼されない限り、練習問題の追加を python-practice リポジトリにコミットします。
ステップ 4:学習コンテキストを確認する

/home/laborant/repos/python-practice/learning-log.md があれば開きます。なければ、references/learning-log.md の初期構成をコピーします。

次の点を確認します。

  • 繰り返し起きる間違い
  • ユーザーが何度も尋ねる確認事項
  • すでに身についている概念
  • 分野の目標と現在の注力点
  • 直近の練習問題一式
  • 過去の日付の練習問題フォルダー

scripts/progress_tracker.py、progress.json、または非公開の採点システムは使用しないでください。レビューの後、および重要な確認事項があった後は、学習ログを直接更新します。

ステップ 5:難易度と分野を選ぶ

references/topic-catalog.md を使用します。 ユーザーがバックエンド、FastAPI、Flask、AWS の自動化、CLI/ツール、データユーティリティ、またはキャップストーンの方向性を希望する場合は、references/practice-tracks.md を使用します。

デフォルトの進行:

  • 難易度 1/5:言語の基礎と小規模な単一ファイルの課題
  • 難易度 2/5:関数、モジュール、テスト、例外、型ヒント、標準ライブラリ
  • 難易度 3/5:実践的なスクリプト、CLI、バックエンドのハンドラー、AWS 自動化の境界
  • 難易度 4/5:FastAPI、Flask、AWS 自動化、またはパッケージを使ったプロジェクト形式の課題
  • 難易度 5/5:段階的なテストを伴う、キャップストーン形式のパッケージまたはサービスの開発

学習ログに応じて調整します:

  • 構文や型に関する混乱が繰り返される場合 → 難易度を下げ、概念を切り分けます。
  • 「なぜこの抽象化を使うのか」という質問が繰り返される場合 → 設計レビューまたはパッケージ境界の課題を含めます。
  • テストに関する混乱が繰り返される場合 → pytest のフィクスチャ/モックの練習を含めます。
  • 基礎がしっかりしている場合 → バックエンド、自動化、AWS、プロジェクト形式の演習へ移行します。
  • ユーザーが難しい課題を希望する場合 → テストと現実的な制約を伴う難易度 3/5 または 4/5 にします。
ステップ 6:演習を作成する

ファイルを作成する前に references/exercise-templates.md を読みます。

デフォルトの演習セット:

  • 1 つの補完演習
  • 1 つのデバッグ演習
  • テスト付きのバックエンド/自動化/フレームワークの応用演習 1 つ

演習セットの構成を調整します:

  • ユーザーがバグに苦戦している場合 → デバッグ演習を 2 つにします。
  • ユーザーが確認質問を多くする場合 → 概念の練習 1 つ、ガイド付きの補完演習 1 つ、応用課題 1 つにします。
  • ユーザーが上級者の場合 → バックエンド、AWS 自動化、テスト、ユーティリティにまたがる応用課題を 3 つにします。

モード別の出力:

  • drill:ファイル 1 つとテスト。
  • debug:壊れたファイル 1 つとテスト、または 1 つの焦点を絞ったパッケージに 3 つのバグ。
  • applied:README とテストを含む小規模なモジュール/パッケージ。
  • pr-simulation:失敗するテストとレビュー用プロンプトを含む、小規模な既存スタイルのパッケージ。
  • design-review:有用な場合に限り、Markdown のプロンプトとスケルトンパッケージ。
  • capstone:README、段階的なテスト、学習ログのチェックポイントを含むモジュール。

ファイル名:

NN_<topic>_<subtopic>_<type>.py
NN_<topic>_<subtopic>_<type>_test.py

各日付フォルダーでは NN を 01 から始めます。日付フォルダーにすでに演習がある場合は、既存の番号のうち最も大きい番号の次から続けます。

パッケージ単位の演習では、以下を作成します:

<date-folder>/NN_<topic>_<subtopic>/
  README.md
  pyproject.toml
  src/<package_name>/...
  tests/...

すべての演習に以下を含めます:

  • トピック、難易度、分野、着想元を記した短いヘッダーコメント/docstring。
  • 明確な目標。
  • 補完課題には TODO マーカー、デバッグ課題には意図的に壊したコード。
  • 最初は失敗するテスト。
  • 有用な場合は、現実的なバックエンド/AWS/フレームワークの設定。
  • コメントに隠された答えを含めないこと。
  • ユーザーから明示的に求められない限り、完全な解答を含めないこと。

まず標準ライブラリを優先します。FastAPI、Flask、boto3、pandas などのライブラリは演習で特に必要な場合にのみ使用します。それ以外の場合は、小さな関数やプロトコルで境界をシミュレートし、セットアップを簡単に保ちます。

ステップ 7:演習が正しく失敗することを確認する

日付フォルダーまたは特定のパッケージフォルダーから実行します:

python -m pytest

インラインテスト付きの単一ファイル演習では、以下を実行します:

python <exercise_file.py>

期待される動作:ユーザーが取り組む必要があるため、生成した演習は失敗するはずです。ユーザーが編集する前に演習が合格する場合は、不足している作業を明示し、再実行します。

バックエンド、AWS の自動化、フレームワークの演習では、本番環境の Python において再現可能なテストが有益なため、pytest を優先します。

ステップ 8:ユーザーに提供する

以下の構成を使用します:

Created <count> Python exercise(s) on <topic> at Difficulty <N>/5.

Focus:
- <why these exercises were selected from learning-log.md>

Files:
- <path> — <one-line task>
- <path> — <one-line task>
- <path> — <one-line task>

Run: cd /home/laborant/repos/python-practice/<date-folder> && python -m pytest
Send me your solution when ready.
ステップ 9:ユーザーの解答をレビューする

ユーザーからレビューを求められた場合:

  • 演習で設定されている場合に限り、フォーマットや lint を実行します。新しいツールチェーンを独自に追加してはいけません。
  • python -m pytest を実行します。
  • 単一ファイルの演習では、演習の仕様で定められている場合に python <exercise_file.py> を実行します。
  • references/review-guide.md を読みます。
  • まず正確性を確認し、次に Python らしい書き方、最後にバックエンド/AWS/フレームワークの本番運用上の観点を確認します。

レビューでは以下を取り上げます:

  • 合格/失敗したテスト
  • バグやエッジケース
  • Python らしい書き方への改善
  • 型ヒントと API の境界
  • エラー処理
  • テストの品質
  • 該当する場合は、バックエンド/フレームワーク/AWS の本番運用との関連性
ステップ 10:学習ログを更新する

レビューのたびに、/home/laborant/repos/python-practice/learning-log.md を手動で更新します。

記録する項目:

  • 日付フォルダー
  • 完了した演習
  • 見つかった間違い
  • 質問した確認事項
  • 理解が深まった概念
  • まだ苦手な概念
  • 次のバッチの提案

間違いの例:

  • mutable-default-arg
  • missing-return
  • type-confusion
  • exception-swallowed
  • path-string-not-pathlib
  • mock-too-broad
  • fixture-scope-confusion
  • fastapi-dependency-confusion
  • flask-global-state
  • boto3-pagination-missing
  • aws-retry-missing
  • iam-action-too-broad
  • not-pythonic-loop

確認事項の例:

  • "dataclass はどのようなときに使うべきですか?"
  • "モックとフェイクは、どのように使い分ければよいですか?"
  • "ここで pathlib を使うのはなぜですか?"
  • "FastAPI では、バリデーションをどこに記述すべきですか?"
  • "Flask のブループリントは、どのようなときに使うべきですか?"
  • "boto3 のページネーションは、どのように処理すればよいですか?"
  • "このスクリプトを安全に再実行できるようにするには、どうすればよいですか?"

同じカテゴリの確認事項が 2 回出てきた場合は、次のバッチに違いを明確にするための比較演習を含める必要があります。

ステップ 11:対話形式のヘルプ
  • "I'm stuck" -> 答えではなくヒントを出します。以前の間違いに結び付けてください。
  • "Show me the solution" または同等の明示的な依頼 -> 必要最小限の完全な解答を提示し、重要な考え方を説明します。
  • "Explain this concept" -> 小さな Python の例と、実践的な用途を 1 つ使って説明します。
  • "Why this exercise?" -> 学習ログに見られる傾向と対象分野に関連付けて説明します。
  • "Make it harder" -> エッジケース、失敗するケース、バリデーション、冪等性、またはモックのテストを追加します。
  • "Make it easier" -> 概念を 1 つに絞り、外部依存関係を取り除きます。
  • "Review this like backend Python" -> 境界、バリデーション、エラー処理、テスト、API の形を重視します。
  • "Prepare me for AWS automation" -> boto3 形式のクライアント、ページネーション、リトライ、冪等性、ドライランのパターンを使います。
  • "Help me build anything in Python" -> 基礎、パッケージ、テスト、CLI、バックエンド、自動化、応用プロジェクトを順に扱います。

キャップストーンの段階

ユーザーがプロジェクト形式の練習を希望する場合、または複数のバッチを問題なく完了した場合に、キャップストーンを提案します。

  1. python-toolbox:ファイル、JSON、CSV、pathlib、argparse、logging、テスト。
  2. automation-runner:冪等なスクリプト、ドライランの動作、リトライ、レポート。
  3. flask-service:ブループリント、バリデーション、テスト、アプリファクトリーを備えた小規模な Flask API。
  4. fastapi-service:依存関係、Pydantic モデル、ルーター、テストを備えた FastAPI アプリ。
  5. aws-inventory-tool:ページネーション、リトライ、フィルタリング、ドライラン計画に対応した、boto3 形式のコレクター。
  6. backend-worker:リトライ、構造化されたエラー、永続化境界を備えたキュー形式のワーカー。

キャップストーンは、段階的に完了できる規模に抑えてください。各フェーズにテストと学習ログのチェックポイントを設けてください。

オープンソースへの参加準備

学習ログで、次の項目を繰り返しうまくこなせていることがわかったら:

  • 関数、データ構造、例外
  • OOP とパッケージの境界
  • 型ヒントとプロトコル
  • pytest のフィクスチャとモック
  • バックエンドのバリデーションとエラー処理
  • AWS 自動化の安全性に関するパターン
  • Python らしい慣用的なスタイル

Python のオープンソースリポジトリにある小さな課題を読み、変更することを提案します。 コアのランタイム処理に手を加える前に、ドキュメント、テスト、内部ユーティリティから始めてください。

コメント