agentleFS
AgentJDrewAgentJDrew/claude-skill-kit/.claude/skills/python-best-practices/SKILL.md

python-best-practices

Skill0 starsChanged 4 months agoMITView on GitHub

Pythonic code with modern type hints, dataclasses, async patterns, packaging, and testing. Use when writing, reviewing, or refactoring Python — picking type-hint syntax, choosing dataclasses vs Pydantic, structuring async code, laying out a project/pyproject.toml, or setting up pytest.

  • Installs packages

19 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use react-best-practices, typescript-best-practices and 3 more.

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.
  • OpenAISkill

    react-best-practices

    React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.

    Also in 3 projects that use this

  • jaydubya818Skill

    typescript-best-practices

    Use when TypeScript needs focused type-safety, API, or error-handling guidance.

    Also in 3 projects that use this

  • BlockSkill

    frontend-design

    Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.

    Also in 4 projects that use this

  • SentrySkill

    skill-creator

    Create new agent skills following the Agent Skills specification. Use when asked to "create a skill", "add a new skill", "write a skill", "make a skill", "build a skill", or scaffold a new skill with SKILL.md. Guides through requirements, writing, registration, and verification.

    Also in 4 projects that use this

  • GoogleSkill

    tdd

    Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.

    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

19 rules. 0 are common, 1 is distinctive, and 18 are very specific to this project.

  • 0

    Common

    Most of the 15 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 18

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Always type function signatures.

    line 12
  2. Very specific:

    Use X | None union syntax (3.10+) instead of Optional[X].

    line 13
  3. Very specific:

    Use the type alias and def fT type-parameter syntax (3.12+) for generics.

    line 14
  4. Very specific:

    Use TypedDict for structured dicts.

    line 15
  5. Very specific:

    Run mypy --strict or pyright in CI.

    line 16
  6. Very specific:

    Use httpx instead of requests for async HTTP.

    line 28
  7. Very specific:

    Use asyncio.gather for concurrent tasks.

    line 29
  8. Very specific:

    Never call blocking I/O in async functions — wrap legacy blocking code in asyncio.to_thread.

    line 30
  9. Very specific:

    Use async with for resource management (connections, sessions, clients).

    line 31
  10. Very specific:

    Use a src/ layout (src/my_project/...) to prevent accidental imports from the project root.

    line 36
  11. Very specific:

    Put all tool configuration in pyproject.toml (build, deps, ruff, mypy, pytest).

    line 42
  12. Very specific:

    Use Ruff instead of flake8 + isort + black — one tool, 10-100x faster.

    line 43
  13. Distinctive:

    Always use a virtual environment.

    line 49
  14. Very specific:

    Prefer uv (uv venv + uv pip install -e ".[dev]") for speed.

    line 50
  15. Very specific:

    Put shared fixtures in conftest.py.

    line 56
  16. Very specific:

    Prefer unpacking (first, *rest = items), comprehensions over map/filter, and context managers for cleanup.

    line 63
  17. Very specific:

    Use the walrus operator (:=) for assign-and-test, and structural pattern matching (match/case, 3.10+) for dispatch.

    line 64
  18. Very specific:

    Never use bare except:. Catch the most specific exception possible.

    line 69
  19. Very specific:

    Use logger.exception() to capture tracebacks when handling unexpected errors.

    line 71

“Common” is measured: kept by at least 6 in 10 of the 15 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

Python Best Practices

Worked code examples for every section live in reference.md (sibling file). This SKILL.md carries the rules; open reference.md when you need a concrete snippet to copy.

Type Hints (3.12+ Syntax)

  • Always type function signatures. Use built-in generics (list[str], dict[str, int]) — no typing.List/typing.Dict.
  • Use X | None union syntax (3.10+) instead of Optional[X].
  • Use the type alias and def f[T](...) type-parameter syntax (3.12+) for generics.
  • Use TypedDict for structured dicts.
  • Run mypy --strict or pyright in CI. Use # type: ignore sparingly and only with a justification.
  • Examples: see reference.md § Type Hints.

Dataclasses vs Pydantic

  • Dataclasses for domain models and internal structs (no validation needed). Use frozen=True for immutable value objects, slots=True for memory efficiency, field(default_factory=...) for mutable defaults.
  • Pydantic for API boundaries, config files, and external data parsing (validation required). Use Field(...) constraints and @field_validator for custom checks; set model_config = {"strict": True}.
  • Rule of thumb: internal/trusted data → dataclass; external/untrusted input → Pydantic.
  • Examples: see reference.md § Dataclasses vs Pydantic.

Async Patterns

  • Use httpx instead of requests for async HTTP.
  • Use asyncio.gather for concurrent tasks; asyncio.Semaphore to bound concurrency / rate-limit.
  • Never call blocking I/O in async functions — wrap legacy blocking code in asyncio.to_thread.
  • Use async with for resource management (connections, sessions, clients).
  • Examples: see reference.md § Async Patterns.

Project Structure

  • Use a src/ layout (src/my_project/...) to prevent accidental imports from the project root.
  • Mirror packages under tests/ with a conftest.py for shared fixtures.
  • Full tree: see reference.md § Project Structure.

pyproject.toml

  • Put all tool configuration in pyproject.toml (build, deps, ruff, mypy, pytest).
  • Use Ruff instead of flake8 + isort + black — one tool, 10-100x faster. Recommended lint select: ["E", "F", "I", "N", "UP", "B", "SIM", "RUF"].
  • Set requires-python = ">=3.12", [tool.mypy] strict = true, and asyncio_mode = "auto" for pytest.
  • Full template: see reference.md § pyproject.toml.

Virtual Environments

  • Always use a virtual environment. Never install packages globally.
  • Prefer uv (uv venv + uv pip install -e ".[dev]") for speed; standard venv works too.
  • Pin exact versions in a lockfile (uv.lock or a pip freeze-generated requirements.txt).
  • Commands: see reference.md § Virtual Environments.

Testing with pytest

  • Put shared fixtures in conftest.py. Use pytest.mark.parametrize for test variations and the tmp_path fixture for filesystem tests.
  • Name tests by behavior (test_create_user_rejects_duplicate_email), assert on outcomes, and assert error cases with pytest.raises.
  • Mock async dependencies with AsyncMock(spec=...); assert call args.
  • Examples: see reference.md § Testing with pytest.

Pythonic Idioms

  • Prefer unpacking (first, *rest = items), comprehensions over map/filter, and context managers for cleanup.
  • Use the walrus operator (:=) for assign-and-test, and structural pattern matching (match/case, 3.10+) for dispatch.
  • Examples: see reference.md § Pythonic Idioms.

Error Handling

  • Never use bare except:. Catch the most specific exception possible.
  • Define a custom exception hierarchy for the application (e.g. AppError → NotFoundError).
  • Use logger.exception() to capture tracebacks when handling unexpected errors.
  • Examples: see reference.md § Error Handling.

Checklist

  • Every function signature is typed; mypy --strict/pyright clean.
  • Built-in generics + X | None unions; no typing.List/Optional.
  • Dataclasses for internal models, Pydantic at external boundaries.
  • Async uses httpx, gather, bounded concurrency; no blocking I/O in coroutines.
  • src/ layout; all config in pyproject.toml; Ruff configured.
  • Virtual env in use; dependencies pinned in a lockfile.
  • Tests assert behavior + error cases; fixtures in conftest.py.
  • No bare except; custom exception hierarchy; logger.exception() for tracebacks.

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.