agentleFS
PraveensenpaiPraveensenpai/karakuri/skills/build-tooling/python-clean-code/SKILL.md

python-clean-code

Skill0 starsChanged 59 days agoMITView on GitHub

Enforces strict architecture, modern type hints, clean code standards, and quality tooling for Python codebases. Mandates exclusive use of the uv package manager, 100% type annotations, automated ruff linting, isort import sorting, formatting on every change, zero dead code, strict file/function size limits, and role-based folder hierarchy.

  • Installs packages

8 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

14 rules. 0 are common, 4 are distinctive, and 10 are very specific to this project.

  • 0

    Common

    Most of the 8 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 10

    Very specific

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

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

    Never: use raw pip install, poetry, or pipenv.

    line 18
  2. Distinctive:

    Always execute automated quality checks on any file edit:

    line 38
  3. Distinctive:

    All code must include explicit type annotations on variables, function signatures, and return values:

    line 62
  4. Very specific:

    Use int | str | None instead of Optional[Union[int, str]].

    line 65
  5. Very specific:

    Use built-in generics: list[str], dict[str, Any], tuple[int, ...], set[Path].

    line 66
  6. Very specific:

    Every function and method must declare its return type: def process(...) -> None:.

    line 68
  7. Distinctive:

    Avoid untyped nested dictionaries.

    line 71
  8. Very specific:

    Prefer @dataclass(frozen=True, slots=True) or pydantic.BaseModel for data transfer objects.

    line 72
  9. Distinctive:

    Keep modules and functions focused on a single responsibility:

    line 78
  10. Very specific:

    models: must never perform network or disk I/O.

    line 120
  11. Very specific:

    cli: only parses input and presents output.

    line 123
  12. Very specific:

    Pathlib over os.path: Always use pathlib.Path for file manipulation, path joining, and existence checks.

    line 129
  13. Very specific:

    Context Managers: Always use with statements for files, sockets, locks, and network sessions to guarantee resource release.

    line 130
  14. Very specific:

    Pattern Matching: Use match / case statements where appropriate instead of long chains of if/elif isinstance(...).

    line 132

“Common” is measured: kept by at least 6 in 10 of the 8 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-clean-code Skill: Quality, Typing & Architecture Standards

Enforces high-rigor production standards for Python projects. Code must be strictly typed, formatted, organized into role-based submodules, and managed exclusively via uv.


1. Package Management via uv (Mandatory)

Never use raw pip install, poetry, or pipenv. Always manage dependencies and environments through uv:

# Initialize a project or add dependencies
uv init
uv add <package>
uv add --dev ruff mypy pytest

# Execute commands within virtualenv
uv run <command>
uv run python -m <module>

# Sync dependencies
uv sync

2. On Every Change: Lint, Sort Imports & Format

Always execute automated quality checks on any file edit:

# 1. Lint and auto-fix violations (including unused imports, code smells)
uv run ruff check --fix

# 2. Sort imports according to isort standard
uv run ruff check --select I --fix

# 3. Format code style (black-compatible, 88 char line length)
uv run ruff format

# 4. Strict static type check
uv run mypy .

Zero-Tolerance Rules:

  • No # noqa or # type: ignore suppressions without an explicit comment explaining the unfixable upstream reason.
  • Zero dead code: Unused imports, unreachable blocks, and abandoned helper functions must be deleted immediately.

3. 100% Modern Type Hinting

All code must include explicit type annotations on variables, function signatures, and return values:

  1. Modern Union & Collection Syntax (Python 3.10+):
    • Use int | str | None instead of Optional[Union[int, str]].
    • Use built-in generics: list[str], dict[str, Any], tuple[int, ...], set[Path].
  2. Explicit Return Types:
    • Every function and method must declare its return type: def process(...) -> None:.
    • Generator functions must declare Iterator[T] or Generator[Y, S, R].
  3. Structured Data:
    • Avoid untyped nested dictionaries.
    • Prefer @dataclass(frozen=True, slots=True) or pydantic.BaseModel for data transfer objects.

4. Quantitative Size Limits & Modularity

Keep modules and functions focused on a single responsibility:

MetricTargetHard LimitAction if Exceeded
File Length100–200 lines300 linesDecompose into submodules by domain/role
Function Length15–30 lines45 linesExtract sub-routines or pipeline steps
Functions per File4–6 functions8 functionsSeparate responsibilities into dedicated files
Files per Subpackage3–5 files7 filesGroup related logic into a subfolder with __init__.py
Function Parameters1–3 parameters4 parametersEncapsulate parameters in a @dataclass or config model

5. Role-Based Directory Architecture

Structure packages by responsibility instead of a flat dump of scripts:

src/<package_name>/
├── __init__.py
├── __main__.py              # Entrypoint invocation (python -m <pkg>)
├── exceptions.py            # Domain-specific typed exception classes
├── cli/                     # CLI parsing (Click, Typer, or Argparse)
│   ├── __init__.py
│   └── main.py
├── models/                  # Pure data structures (Dataclasses / Pydantic)
│   ├── __init__.py
│   └── entity.py
├── services/                # Core business logic and orchestration
│   ├── __init__.py
│   └── processor.py
├── client/ (or api/)        # External HTTP/network clients (httpx, requests)
│   ├── __init__.py
│   └── remote.py
├── storage/ (or db/)        # File persistence, SQLite, caching
│   ├── __init__.py
│   └── repository.py
└── utils/                   # Reusable formatters, time helpers, validators
    ├── __init__.py
    └── format.py

Module Boundaries:

  • models must never perform network or disk I/O.
  • storage encapsulates file read/write operations and schema migrations.
  • services coordinates business workflows by calling clients and storage.
  • cli only parses input and presents output; no domain logic inside CLI handlers.

6. DRY & Modern Idioms

  1. Pathlib over os.path: Always use pathlib.Path for file manipulation, path joining, and existence checks.
  2. Context Managers: Always use with statements for files, sockets, locks, and network sessions to guarantee resource release.
  3. Structured Exceptions: Define clear, custom exceptions in exceptions.py inheriting from Exception rather than raising generic RuntimeError or ValueError.
  4. Pattern Matching: Use match / case statements where appropriate instead of long chains of if/elif isinstance(...).

7. Pre-Commit Verification Checklist

# Auto-fix linting & import sorting
uv run ruff check --fix
uv run ruff check --select I --fix

# Format code
uv run ruff format

# Static type verification
uv run mypy .

# Run test suite
uv run pytest

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.