python-type-safety
Skill2 starsChanged 5 months agoApache-2.0View on GitHub
Enforce consistent type hint usage across the atlas project. Covers annotation style, `from __future__ import annotations`, Literal and Protocol patterns, TYPE_CHECKING for optional dependencies, and recommended type checker config. Use when writing or reviewing type annotations.
7 other projects use a version of this.
Adopted by
Most recently taken up by
- liushikuan63/Qoder-Optimizationtheir own version, first seen Nov 1, 2026
- anton-karlovskiy/deal-hunter-agentstheir own version, first seen Oct 13, 2026
- roshankodi/agent-skillstheir own version, first seen Sep 22, 2026
- drzioner/gitwisetheir own version, first seen Jul 22, 2026
- NorkzYT/claude-code-autopilottheir own version, first seen Jun 11, 2026
- gabepublic/api-autonom-test-01their own version, first seen Apr 24, 2026
Other versions7 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 7
- CodeWithBehnam/cc-docs★ 2same name
- liushikuan63/Qoder-Optimization★ 2same name
- NorkzYT/claude-code-autopilot★ 2same name
- roshankodi/agent-skills★ 2same name
- anton-karlovskiy/deal-hunter-agents★ 1same name
- drzioner/gitwise★ 1same name
- gabepublic/api-autonom-test-01★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository16 other files it gives its agents.
- architecture-decision-recordsSkill
- atlas-add-toolSkill
- atlas-build-bundleSkill
- atlas-ci-releaseSkill
- atlas-optimization-patternsSkill
- atlas-rag-evaluationSkill
- embedding-strategiesSkill
- hybrid-search-implementationSkill
- mcp-builderSkill
- python-code-styleSkill
- python-observabilitySkill
- python-resilienceSkill
- python-testing-patternsSkill
- readme-maintenanceSkill
- skill-creatorSkill
- uv-package-managerSkill
The file
We split this skill into the rules it gives an agent
7 rules. 0 are common, 2 are distinctive, and 5 are very specific to this project.
0
Common
Most of the 7 edited versions we read keep these.
2
Distinctive
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 37
Every function must have annotated parameters and return type.
- Very specific: line 45
Use built-in generic types (list[str], dict[str, Any], tuple[str, str]) — these are available in Python 3.9+ and compatible with the from …
- Very specific: line 49
Use Literal when a parameter accepts only a fixed set of string values:
- Very specific: line 61
When a module imports a heavy or optional dependency only for type-checking, gate it behind TYPE_CHECKING and provide a runtime fallback:
- Very specific: line 84
Use abc.ABC and @abstractmethod for defining interfaces:
- Very specific: line 123
Create pyproject.toml section or mypy.ini:
- Distinctive: line 153
Run this before the build step so type errors fail fast.
“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.
Files
When to use
- Annotating new Python code
- Reviewing PRs for type correctness
- Setting up a type checker (mypy or pyright) for the project
- Debugging a type-related issue
Project conventions
from __future__ import annotations
Required in every .py file (after the module docstring):
"""Module docstring."""
from __future__ import annotationsThis defers all annotation evaluation to strings, which:
- Eliminates runtime import overhead for annotations
- Allows forward references without quotes
- Works naturally with
requires-python = ">=3.11"
Parameter and return type annotations
Every function must have annotated parameters and return type.
def parse_frontmatter(text: str) -> tuple[dict, str]: ...
def embed(self, texts: list[str]) -> np.ndarray: ...
def chunk_file(path: Path, repo_root: Path) -> list[dict]: ...Use built-in generic types (list[str], dict[str, Any], tuple[str, str]) — these are available in Python 3.9+ and compatible with the from __future__ import annotations approach.
Literal for constrained values
Use Literal when a parameter accepts only a fixed set of string values:
from typing import Literal
Backend = Literal["mlx", "onnx-cpu", "onnx-gpu", "auto"]This enables the type checker to validate callers and provides autocomplete in IDEs.
TYPE_CHECKING for optional dependencies
When a module imports a heavy or optional dependency only for type-checking, gate it behind TYPE_CHECKING and provide a runtime fallback:
from typing import TYPE_CHECKING
if TYPE_CHECKING:
import mlx.core as mx
def _import_mlx() -> None:
try:
import mlx.core as mx
except ImportError:
raise ImportError(
"MLX backend requires 'mlx' package. "
"Install with: uv sync --extra mlx"
)This pattern is used in atlas/embed/mlx.py for the MLX backend.
Abstract base classes with abc.ABC
Use abc.ABC and @abstractmethod for defining interfaces:
from abc import ABC, abstractmethod
class Embedder(ABC):
dim: int
@abstractmethod
def embed(self, texts: list[str]) -> np.ndarray: ...What to avoid
| Don't use | Why | Instead |
typing.List, typing.Dict | Deprecated in Python 3.9 | list, dict |
typing.Optional | Redundant with Union[X, None] syntax | X | None (Python 3.10+) |
Unannotated self / cls | Unnecessary — type checkers infer these | Omit |
Any where a concrete type exists | Loses all type safety | Narrow to the actual type |
Any usage
Any is reserved for genuinely dynamic types:
- JSON payloads with unknown structure
**kwargsthat forward to third-party libraries- Generic dict values where the value type varies
def handler(arguments: dict[str, Any]) -> str: ...Recommended type checker setup
The project has no type checker configured (no mypy.ini, no pyrightconfig.json). Recommended:
mypy
Create pyproject.toml section or mypy.ini:
[tool.mypy]
python_version = "3.11"
strict = true
ignore_missing_imports = truepyright
Create pyrightconfig.json:
{
"include": ["atlas"],
"pythonVersion": "3.11",
"typeCheckingMode": "strict"
}CI integration
Once a type checker is configured, add a step to build-bundle.yml:
- name: Type check
run: uv run mypy atlas/Run this before the build step so type errors fail fast.
References
atlas/embed/base.py— ABC + Literal patternatlas/embed/mlx.py— TYPE_CHECKING patternatlas/embed/onnx.py— parameter annotations withsnapshot_downloadatlas/chunk.py— return type annotations with complex types
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
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.

