agentleFS
sagar-shirwalkarsagar-shirwalkar/servicenow-atlas/.agents/skills/python-type-safety/SKILL.md

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

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
  1. Distinctive:

    Every function must have annotated parameters and return type.

    line 37
  2. Very specific:

    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 …

    line 45
  3. Very specific:

    Use Literal when a parameter accepts only a fixed set of string values:

    line 49
  4. Very specific:

    When a module imports a heavy or optional dependency only for type-checking, gate it behind TYPE_CHECKING and provide a runtime fallback:

    line 61
  5. Very specific:

    Use abc.ABC and @abstractmethod for defining interfaces:

    line 84
  6. Very specific:

    Create pyproject.toml section or mypy.ini:

    line 123
  7. Distinctive:

    Run this before the build step so type errors fail fast.

    line 153

“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

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 annotations

This 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 useWhyInstead
typing.List, typing.DictDeprecated in Python 3.9list, dict
typing.OptionalRedundant with Union[X, None] syntaxX | None (Python 3.10+)
Unannotated self / clsUnnecessary — type checkers infer theseOmit
Any where a concrete type existsLoses all type safetyNarrow to the actual type

Any usage

Any is reserved for genuinely dynamic types:

  • JSON payloads with unknown structure
  • **kwargs that 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 = true

pyright

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 pattern
  • atlas/embed/mlx.py — TYPE_CHECKING pattern
  • atlas/embed/onnx.py — parameter annotations with snapshot_download
  • atlas/chunk.py — return type annotations with complex types

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.