checking-types_skill

Overview

This skill runs configured Python type checkers automatically after editing .py files to help validate type safety. It integrates with pyrefly and mypy when declared in pyproject.toml and executes the preferred tool(s) in priority order. The hook is internal-only and passive: it runs post-edit to surface type issues early without blocking edits.

How this skill works

When a Python file is edited or written, the PostToolUse hook triggers a type-check step. The skill looks for [tool.pyrefly] and [tool.mypy] sections in pyproject.toml and runs the corresponding scripts. Execution priority prefers pyrefly first (uv run pyrefly), then mypy (uv run mypy) if pyrefly is not configured or after it completes.

When to use it

• Validate type annotations after editing Python source files (.py).
• Catch type errors early during development without manual commands.
• Enforce project-level type-check configuration defined in pyproject.toml.
• Run as an internal passive hook in CI-like local workflows.
• Complement linting and unit tests with static type verification.

Best practices

• Declare pyrefly or mypy under [tool.*] in pyproject.toml to enable checks.
• Prefer pyrefly as the primary checker if configured, falling back to mypy.
• Keep type-check scripts in project tooling (e.g., use uv run <tool>) for consistent execution.
• Run type checks on the modified file to minimize noise and speed feedback.
• Treat this as a feedback mechanism, not a blocking gate for quick edits.

Example use cases

• A developer edits a module and wants immediate feedback on broken or missing annotations.
• A team enforces type-safety standards by adding pyrefly or mypy to pyproject.toml.
• Local pre-commit style: quickly surface type regressions without running full test suites.
• Tooling that integrates editor saves with automated static checks for faster iteration.