agentleFS
kumaran-iskumaran-is/claude-code-onboarding/.claude/skills/python-dev/SKILL.md

python-dev

Skill35 starsChanged 6 months agoMITView on GitHub

This skill provides patterns and templates for Python 3.14 development with FastAPI and modern tooling. It should be activated when creating Python APIs, scripts, data processing pipelines, or pytest tests.

  • Reads credentials
  • Installs packages

10 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use rust-dev and go-dev.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • docckerSkill

    rust-dev

    Rust 开发规范(聚焦 Axum + Tokio 后端栈),覆盖工具链、错误处理、异步陷阱、模块组织、依赖管理与测试规范

    Also in 3 projects that use this

  • mahdy-gribkovSkill

    go-dev

    Writes, reviews and lints Go code, with idiomatic error handling, table-driven tests, golangci-lint v2 configuration, and a one-command run of format, lint, vet, tidy, govulncheck and race tests. Use when working on a .go file or go.mod, reviewing a Go PR or function, asking "is this idiomatic Go", setting up or fixing golangci-lint, writing Go tests, or chasing a Go lint, vet or race failure. Not for other languages.

    Also in 3 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

16 rules. 0 are common, 5 are distinctive, and 11 are very specific to this project.

  • 0

    Common

    Most of the 7 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 11

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use Python 3.14 with type hints everywhere

    line 22
  2. Very specific:

    Use uv for package management, ruff for linting, mypy for types

    line 25
  3. Very specific:

    Code templates and project config: Read reference/fastapi-templates.md for FastAPI app structure, Pydantic models, route handlers, …

    line 48
  4. Very specific:

    Advanced patterns and profiling: Read reference/python-advanced-patterns.md for performance profiling (cProfile, py-spy, memory_profiler), …

    line 50
  5. Very specific:

    Auth, security and authorization: Read reference/fastapi-auth-security.md for JWT tokens (python-jose), bcrypt password hashing (cost 12), …

    line 52
  6. Very specific:

    Error handling, retry, and circuit breakers: Read reference/fastapi-error-handling.md for custom exception hierarchy (AppError → …

    line 54
  7. Distinctive:

    Read reference files: when you need specific templates or configuration

    line 65
  8. Very specific:

    Format and type-check: Run ruff format, ruff check --fix, and mypy

    line 73
  9. Distinctive:

    Before generating code, consult these sources for current syntax and APIs:

    line 90
  10. Very specific:

    API errors: Always raise HTTPException with descriptive detail messages.

    line 99
  11. Very specific:

    Use str | None union syntax (Python 3.10+), not Optional[str]

    line 139
  12. Very specific:

    Use model_validator for cross-field Pydantic validation, not ad-hoc __init__ logic

    line 140
  13. Very specific:

    Use the /scaffold-python-worker command to create the service structure

    line 146
  14. Distinctive:

    All failures MUST be logged via structlog and surfaced as status records — never swallowed

    line 149
  15. Very specific:

    After implementation: dispatch python-worker-reviewer agent for review

    line 151
  16. Distinctive:

    After writing Python code, dispatch these reviewer agents:

    line 155

“Common” is measured: kept by at least 6 in 10 of the 7 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Iron Law

NO FASTAPI ENDPOINT WITHOUT A PYDANTIC v2 INPUT MODEL — never trust raw request data; validate at the boundary, always

Python 3.14 Development Skill

Code Conventions

  • Use Python 3.14 with type hints everywhere
  • FastAPI for REST APIs, Pydantic v2 for validation
  • Async by default: async def endpoints, asyncpg for PostgreSQL
  • Use uv for package management, ruff for linting, mypy for types
  • Folder structure: api/routes/ → services/ → repositories/ → models/
  • Tests: pytest + pytest-asyncio + httpx

Quick Scaffold — New Python Project

# Using uv (preferred)
uv init my-service
cd my-service
uv add fastapi uvicorn pydantic pydantic-settings
uv add --dev pytest pytest-asyncio httpx ruff mypy

# Or using pip
mkdir my-service && cd my-service
python -m venv .venv
source .venv/bin/activate    # Windows: .venv\Scripts\activate
pip install fastapi uvicorn pydantic pydantic-settings
pip install -e ".[dev]"

Reference Files

Code templates and project config: Read reference/fastapi-templates.md for FastAPI app structure, Pydantic models, route handlers, SQLAlchemy models, pytest fixtures, pyproject.toml template, Docker configuration, and common commands.

Advanced patterns and profiling: Read reference/python-advanced-patterns.md for performance profiling (cProfile, py-spy, memory_profiler), pytest-benchmark, property-based testing with Hypothesis, structural pattern matching, descriptors, and memory optimization techniques.

Auth, security and authorization: Read reference/fastapi-auth-security.md for JWT tokens (python-jose), bcrypt password hashing (cost 12), OAuth2PasswordBearer dependency injection, RBAC role hierarchy, PBAC permission maps, resource ownership checks, auth-specific rate limit configuration, and pytest auth test patterns.

Error handling, retry, and circuit breakers: Read reference/fastapi-error-handling.md for custom exception hierarchy (AppError → NotFoundError/ValidationError/ExternalServiceError), FastAPI exception handlers, async retry with tenacity, async circuit breaker with circuitbreaker, error logging context middleware, and pytest patterns for error paths.

Backend service consistency patterns: Read reference/backend-service-patterns.md for 12 mandatory patterns covering all services/backend/<service>/ code: timing-safe internal secret guard (P1), fail-fast config fields (P2), structlog naming (P3), session ownership (P4), Pub/Sub singleton (P5), fire-and-forget (P6), Redis lifecycle (P7), DB count queries (P8), GCS URI validation (P9), shared auth helpers (P10), no hardcoded config (P11), DRY shared utilities (P12). Includes pre-commit grep gates and new/modified service checklists.

Live E2E integration testing: Read reference/backend-live-e2e-standard.md for why unit tests (ASGITransport + mocks) miss real integration bugs, the per-service test pattern (health, auth gate, fake JWT rejection, internal secret gate, input validation), auth ordering rules (FastAPI validates auth before Pydantic), HTTP method verification from OpenAPI spec, and the feedback loop for fixing live failures.

Pub/Sub and Firestore messaging patterns: Read reference/pubsub-firestore-patterns.md for the three canonical messaging patterns: Pattern A (fire-and-forget asyncio.create_task for informational events), Pattern B (transactional outbox with SELECT FOR UPDATE SKIP LOCKED for load-bearing events), Pattern C (Firestore status bus for real-time mobile UI). Includes decision tree, full implementation templates, subscriber patterns, and hard rules for each.

Process

  1. Scaffold project structure using uv or pip commands above
  2. Read reference files when you need specific templates or configuration
  3. Create folder structure: src/my_service/ with subfolders api/routes/, models/, services/, core/
  4. Write main.py using FastAPI app template with lifespan context manager
  5. Define Pydantic models for request/response validation in models/
  6. Implement route handlers in api/routes/ with proper HTTP methods and status codes
  7. Add business logic in services/ layer (keep routes thin)
  8. Configure environment using pydantic-settings in core/config.py
  9. Write tests with pytest-asyncio and AsyncClient fixtures
  10. Format and type-check: Run ruff format, ruff check --fix, and mypy

Key Patterns

PatternImplementation
Type hintsUse everywhere: def func(x: int) -> str:
Async by defaultAll I/O-bound operations use async def and await
ValidationPydantic models for all API inputs/outputs
Configpydantic-settings with .env file support
Dependency injectionFastAPI Depends() for services and repositories
Error handlingRaise HTTPException with appropriate status codes
DatabaseSQLAlchemy 2.0+ with async session and Mapped[] types
Testingpytest with fixtures, httpx AsyncClient, 80%+ coverage

Documentation Sources

Before generating code, consult these sources for current syntax and APIs:

SourceURL / ToolPurpose
Pydantic v2https://docs.pydantic.dev/latest/llms-full.txtModel validation, Field constraints, settings
FastAPI / PythonContext7 MCPLatest FastAPI endpoints, dependencies, middleware

Error Handling

API errors: Always raise HTTPException with descriptive detail messages.

from fastapi import HTTPException

if not user:
    raise HTTPException(status_code=404, detail="User not found")

if not has_permission:
    raise HTTPException(status_code=403, detail="Insufficient permissions")

Validation errors: Pydantic automatically returns 422 with validation details. Use Field() constraints for business rules.

Database errors: Catch SQLAlchemy exceptions in service layer and convert to appropriate HTTP exceptions.

from sqlalchemy.exc import IntegrityError

try:
    await session.commit()
except IntegrityError:
    raise HTTPException(status_code=409, detail="Email already exists")

Common Commands

uvicorn src.main:app --reload                          # Run dev server (hot reload)
pytest -q                                              # Run tests (quiet output)
pytest -q --cov=src --cov-report=term-missing          # Tests with coverage
ruff check --fix .                                     # Lint and auto-fix
ruff format .                                          # Format code
mypy src/                                              # Type check
alembic upgrade head                                   # Run pending migrations
alembic revision --autogenerate -m "description"       # Generate new migration

Hard Prohibitions

  • Use str | None union syntax (Python 3.10+), not Optional[str]
  • Use model_validator for cross-field Pydantic validation, not ad-hoc __init__ logic

Background Worker Services

For Pub/Sub, Cloud Scheduler, or GCS-triggered workers (NOT FastAPI REST APIs):

  • Use the /scaffold-python-worker command to create the service structure
  • Entry point: async def run_job(payload: dict) -> JobResult: in src/job.py
  • External clients (APIs, cloud services) MUST be injected — never instantiated inline
  • All failures MUST be logged via structlog and surfaced as status records — never swallowed
  • Required env vars MUST have NO defaults in config — missing values raise ValidationError at startup
  • After implementation: dispatch python-worker-reviewer agent for review

Post-Code Review

After writing Python code, dispatch these reviewer agents:

  • code-reviewer — general quality, DRY, error handling
  • python-worker-reviewer — if this is a background worker service (Pub/Sub/Cloud Scheduler/GCS): silent failures, client injection, DB access patterns, structlog usage, test coverage
  • security-reviewer — input validation, auth, dependency audit

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.