Back to Skills

pyrefly-type-coverage

Migrate a file to use stricter Pyrefly type checking with annotations required for all functions, classes, and attributes.

101,539stars28,276forksUpdated 7/7/2026

Security Assessment

Safe(100/100)
Security Score100/100

About pyrefly-type-coverage

A guided procedure for migrating a single Python file to stricter Pyrefly type checking, where annotations are required for all functions, parameters, classes, and attributes. It is written for the PyTorch codebase and assumes the file lives in a project with a pyrefly.toml and that pyrefly, lintrunner, and the test runner are on PATH — if any are missing, it says to stop and ask about activating a conda environment rather than installing substitutes.

The workflow has four steps. First, remove file-level suppressions such as # pyre-ignore-all-errors, its bracketed variants, # @lint-ignore-every PYRELINT, and # mypy: ignore-errors. Second, add a [[sub-config]] entry to pyrefly.toml matching the directory and enabling the strict error keys (unannotated-return, unannotated-parameter, implicit-any), with a caution that turning these on resurfaces previously hidden errors and that unrelated categories can be mirrored from the parent config to silence them. Third, run pyrefly check on the file. Fourth, add annotations to resolve the three target categories, which must never be suppressed except for a single @compatibility(is_backward_compatible=True) carve-out.

Much of the value is in the detailed annotation conventions: PEP 604 / PEP 585 syntax, preferring collections.abc over typing, always parameterizing Callable (favoring Callable[..., object]), using TypeVar and ParamSpec when a return type derives from a parameter, TypeGuard or TypeIs for boolean predicates, class-level annotations for attributes set in __init__, and breaking import cycles with TYPE_CHECKING plus from __future__ import annotations. It also encodes a torch naming convention (leading underscores for introduced module-local globals) and a widening ladder — most specific type, then a union or bound TypeVar, then object, and only as a last rung Any — so annotations widen deliberately instead of reaching for an ignore. Errors originating outside the target file are left alone or suppressed at the report site with a TODO comment.

FAQ

What are the prerequisites for running this skill?

The file must live in a project with a pyrefly.toml, and pyrefly, lintrunner, and the test runner must be on PATH; if any are missing, the skill says to stop and ask whether a conda environment needs activating.

Which error categories must always be fixed rather than suppressed?

unannotated-return, unannotated-parameter, and implicit-any — these three are always resolvable by adding an annotation, with the only exception being the @compatibility(is_backward_compatible=True) carve-out.

How do you enable stricter checking for a file?

Add a [[sub-config]] entry to pyrefly.toml that matches the directory and sets keys like unannotated-return, unannotated-parameter, and implicit-any, then run pyrefly check on the file.

What annotation style does it recommend?

PEP 604/585 syntax (int | None, list[str]), collections.abc over typing for ABCs, always-parameterized Callable, and TypeVar or ParamSpec when a return type is derived from a parameter.

What should you do when the correct type is hard to infer?

Follow the widening ladder — most specific concrete type, then a union or bound TypeVar, then object, and only as a last resort Any — rather than suppressing the error.

Install pyrefly-type-coverage

Download and extract the skill files to your .claude/skills/ directory.

Quick Setup:

  1. Copy the skill folder to .claude/skills/
  2. Claude will automatically detect and use the skill

Repository

pytorch/pytorch