plugins/python/skills/typing-patterns/SKILL.md
# Python Typing Patterns Python type annotation patterns without `type: ignore`. Always the correct solution. ## Triggers Use this skill when the user: - Gets mypy/pyright errors - Asks about Python type annotations - Wants to add type hints - Works with generics, protocols, TypeVar ## Main Principle: NEVER type: ignore Every type error has a correct solution. `type: ignore` is: - Masking potential bugs - Disabling type checking - Technical debt More details: `${CLAUDE_PLUGIN_ROOT}/skills/
npx skillsauth add ruslan-korneev/claude-plugins plugins/python/skills/typing-patternsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Python type annotation patterns without type: ignore. Always the correct solution.
Use this skill when the user:
Every type error has a correct solution. type: ignore is:
More details: ${CLAUDE_PLUGIN_ROOT}/skills/typing-patterns/references/why-no-type-ignore.md
More details: ${CLAUDE_PLUGIN_ROOT}/skills/typing-patterns/references/dict-typing.md
# Bad: Weak level
def process(data: dict): ...
# Warning: Medium level
def process(data: dict[str, Any]): ...
# Good: Strong level
class UserData(TypedDict):
id: int
email: str
name: str
def process(data: UserData): ...
Why TypedDict is better:
data["emial"] → error)When dict[K, V] is acceptable:
dict[str, User], dict[int, float]# Primitives
x: int = 1
y: str = "hello"
z: bool = True
f: float = 1.5
# Collections (built-in)
items: list[str] = ["a", "b"]
mapping: dict[str, int] = {"a": 1}
unique: set[int] = {1, 2, 3}
pair: tuple[int, str] = (1, "a")
# Union (Python 3.10+)
value: int | str = 1
optional: str | None = None
# Callable
from collections.abc import Callable
handler: Callable[[int, str], bool] = lambda x, s: True
More details: ${CLAUDE_PLUGIN_ROOT}/skills/typing-patterns/references/generics.md
from typing import TypeVar, Generic
T = TypeVar("T")
K = TypeVar("K")
V = TypeVar("V")
class Repository(Generic[T]):
def get(self, id: int) -> T | None: ...
def save(self, item: T) -> T: ...
# Usage
class UserRepository(Repository[User]):
pass
# Python 3.12+ syntax
class Repository[T]:
def get(self, id: int) -> T | None: ...
from typing import Protocol
class Readable(Protocol):
def read(self) -> str: ...
class Writable(Protocol):
def write(self, data: str) -> None: ...
# Structural subtyping — no explicit inherit needed
class MyFile:
def read(self) -> str:
return "content"
def process(source: Readable) -> str:
return source.read()
process(MyFile()) # OK — MyFile implements Readable
from typing import TypeVar
# Bound — only subtypes
T = TypeVar("T", bound=BaseModel)
def validate(model: T) -> T:
# model is guaranteed to have BaseModel methods
return model
# Constraints — only specific types
S = TypeVar("S", str, bytes)
def process(data: S) -> S:
# data is either str or bytes
return data
from typing import overload
@overload
def process(x: int) -> int: ...
@overload
def process(x: str) -> str: ...
def process(x: int | str) -> int | str:
if isinstance(x, int):
return x * 2
return x.upper()
from typing import TypeGuard
def is_string_list(val: list[object]) -> TypeGuard[list[str]]:
return all(isinstance(x, str) for x in val)
items: list[object] = ["a", "b", "c"]
if is_string_list(items):
# mypy knows: items is list[str]
print(items[0].upper())
# Bad
def get_name(user: User | None) -> str:
return user.name # Error: Item "None" has no attribute "name"
# Good
def get_name(user: User | None) -> str:
if user is None:
raise ValueError("User is required")
return user.name
# Bad
def process(x):
return x * 2
# Good
def process(x: int) -> int:
return x * 2
# Bad
items = [] # Need type annotation
# Good
items: list[str] = []
# Bad
def register(callback):
...
# Good
from collections.abc import Callable
def register(callback: Callable[[int], str]) -> None:
...
# Or with ParamSpec for exact signature passing
from typing import ParamSpec, TypeVar
P = ParamSpec("P")
R = TypeVar("R")
def decorator(func: Callable[P, R]) -> Callable[P, R]:
def wrapper(*args: P.args, **kwargs: P.kwargs) -> R:
return func(*args, **kwargs)
return wrapper
[tool.mypy]
python_version = "3.12"
strict = true
warn_return_any = true
warn_unused_ignores = true
disallow_untyped_defs = true
disallow_untyped_calls = true
{
"typeCheckingMode": "strict",
"pythonVersion": "3.12"
}
/types:check [path] — check types/types:explain <error> — explain error + solutiontools
# Code Review Skill This skill should be used when the user asks for "code review", "review my changes", "review this PR", "check my code", "pre-merge review", "review diff", or mentions reviewing code quality, implementation correctness, or preparing changes for merge. ## Overview Code review following the **Review Pyramid** methodology — a prioritized approach that focuses on what matters most. ## The Review Pyramid ``` ▲ /|\ 5. Code Style (Nit) ← Least important,
tools
# Architecture Patterns System-level architecture patterns for Python backend projects (FastAPI + SQLAlchemy 2.0). ## Triggers Use this skill when the user: - Designs a new system or major feature - Asks about project structure or module boundaries - Makes data modeling decisions - Designs API contracts - Evaluates architectural trade-offs - Creates or reviews Architecture Decision Records (ADR) - Needs to modernize legacy code ## Abstraction Levels | Plugin | Level | Focus | |--------|----
tools
# Ruff Patterns Knowledge about the ruff linter and patterns for solving errors. **ZERO noqa policy** — always look for the proper solution. ## Triggers Use this skill when the user: - Asks "how to configure ruff" - Gets a ruff error and wants to understand how to fix it - Wants to migrate from black/isort/flake8/pylint - Asks about a specific rule (E501, F401, etc.) ## Main Principle: NEVER USE NOQA **Every ruff error has a proper solution.** Using `# noqa` is: - Hiding the problem, not so
tools
# Pytest Patterns Quality testing patterns with pytest for FastAPI projects. **TDD-first approach**. ## Triggers Use this skill when the user: - Wants to write tests - Asks about pytest, fixtures, mocks - Wants to set up testing for FastAPI - Uses TDD approach ## Main Principle: TDD 1. **Red** — write a failing test 2. **Green** — write minimal code 3. **Refactor** — improve while keeping tests green ## What Makes a Good Test ### 1. Clear Name ```python # ✅ Good — describes what, when, a