home / skills / git-fg / thecattoolkit / checking-types

checking-types skill

safe

/plugins/sys-core/skills/checking-types

This skill runs configured type checkers on edited Python files to ensure type safety and early bug detection.

npx playbooks add skill git-fg/thecattoolkit --skill checking-types

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

812 B

---
name: checking-types
description: "Runs configured type checkers (pyrefly, mypy) on files after editing. MUST USE when validating Python type safety (Internal-only passive hook)."
user-invocable: false
allowed-tools: [Read, Bash(pyrefly), Bash(mypy), Bash(python3:-m pyrefly), Bash(python3:-m mypy)]
---

# Type Checking Standards

## Active Hooks


### Automatic Type Check
**Trigger:** `PostToolUse` (Edit/Write on .py files)
**Action:** Runs type checker on the modified file.
**Priority:**
1. `tool.pyrefly` in pyproject.toml -> `uv run pyrefly`
2. `tool.mypy` in pyproject.toml -> `uv run mypy`



## Configuration

To enable type checking for a project, assume the presence of `pyproject.toml` with `[tool.pyrefly]` or `[tool.mypy]`.

**Scripts:**
- `plugins/verify/hooks/scripts/type-check-python.py`

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.

FAQ

Which type checker runs first?

pyrefly is run first if [tool.pyrefly] is present; mypy is run next if configured.

What triggers the check?

The PostToolUse hook triggers after an edit/write action on .py files.