
Pyrefly Type Coverage
FreeEnhance type safety in Python projects with Pyrefly.
Free · Opens the source repo
What Pyrefly Type Coverage does
The Pyrefly Type Coverage skill is designed to assist developers in migrating Python files to adopt stricter type checking using Pyrefly. This skill ensures that all functions, classes, and attributes are properly annotated, which is essential for maintaining code quality and reliability in larger codebases. By enforcing type annotations, it helps prevent common bugs and improves code readability, making it easier for teams to collaborate effectively.
To use this skill, developers must first ensure that their project includes a pyrefly.toml configuration file and that the necessary tools (pyrefly, lintrunner, and the project's test runner) are accessible in the system's PATH. The skill guides users through a series of steps to remove existing type-check suppressions, configure the pyrefly.toml file, and run type checks on the target file. This structured approach helps developers systematically address type-related issues in their code.
The skill is particularly beneficial for teams working on Python projects that require high levels of type safety, such as those in finance, healthcare, or any domain where code reliability is paramount. By integrating this skill into their workflow, developers can ensure that their code adheres to best practices in type checking, ultimately leading to more robust and maintainable software.
However, it is important to note that the skill is not a magic bullet for all type-related issues. Developers will need to manually address certain types of errors, especially those that arise from external dependencies or incorrect usage patterns. The skill provides clear guidelines on how to handle these situations, but users should be prepared to engage with their codebase actively.
When to use it
Use this skill when you need to enforce strict type checking in your Python code to improve maintainability and reduce bugs.
When not to use it
Avoid this skill if your project does not use Pyrefly or if you are not ready to adopt strict typing practices in your codebase.
What you can build with it
Migrating a Legacy Codebase
Use this skill to systematically update an older Python project to enforce strict type checking, improving maintainability.
Team Collaboration on Python Projects
Integrate this skill into your team's workflow to ensure all members adhere to the same type checking standards, enhancing code consistency.
Preparing for Production Deployment
Before deploying a Python application, utilize this skill to ensure all code is properly annotated, reducing the risk of runtime errors.
How to install Pyrefly Type Coverage
View source1. Install with the skills CLI
npx skills add pytorch/pytorch/pyrefly-type-coverage --agent claude-code2. Or install it manually
Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.
Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs
Inside SKILL.md
Written by pytorchPyrefly Type Coverage Skill
Prerequisites
- The file must live in a project with a
pyrefly.toml. pyrefly,lintrunner, and the project's test runner must be on PATH. If any are missing, stop and ask whether a conda environment needs activating — don't install or substitute (per repo CLAUDE.md).
Step 1: Remove file-level type-check suppressions
Delete any of these from the top of the file (pyrefly honors # mypy: ignore-errors
for mypy compat, so that one must go too):
# pyre-ignore-all-errors
# pyre-ignore-all-errors[16,21,53,56]
# @lint-ignore-every PYRELINT
# mypy: ignore-errors
Step 2: Add a sub-config entry to pyrefly.toml
[[sub-config]]
matches = "path/to/directory/**"
[sub-config.errors]
implicit-import = false
implicit-any = true
bad-param-name-override = false
unannotated-return = true
unannotated-parameter = true
IMPORTANT: Setting any error key in [sub-config.errors] overrides only that key
relative to the parent — but enabling unannotated-return / unannotated-parameter /
implicit-any will resurface errors that were previously hidden file-wide. If you see
unrelated errors (e.g., bad-param-name-override) flooding the output, mirror the
parent config's setting for that key in the sub-config to silence them.
Step 3: Run pyrefly
pyrefly check <FILENAME>
Goal: resolve all unannotated-return, unannotated-parameter, and implicit-any
errors by adding annotations — see Step 4's ladder. These three target categories are
always resolvable; never suppress them with # pyrefly: ignore. The single
exception is @compatibility(is_backward_compatible=True) (Step 4).
Other categories (bad-argument-type, missing-attribute, …) are real type bugs.
Handle them by where pyrefly reports them:
- Reported in another file (path != target): leave it. Don't widen scope. If
the error is now blocking the target, suppress at the report site with
# pyrefly: ignore[<category>] # TODO. - Reported in the target file but the message names a symbol defined elsewhere
(e.g.,
bad-returnbecause an imported function's annotation is wrong): suppress locally with the same TODO comment. Don't invent acast()that papers over the upstream gap. - Reported in the target file, originates locally: fix it.
Use # pyrefly: ignore[...] only as a last resort, and only on non-target categories.
Step 4: Add annotations
Examine call sites when the right type isn't obvious from the function body.
Annotation conventions
- Use PEP 604 / PEP 585 syntax (
int | None,list[str]) — assume Python >= 3.10. - Prefer
collections.abcovertypingfor ABCs (Callable,Sequence,Generator, ...). - For generic helpers, import from
typingwhen available on the project's minimum Python version, and fromtyping_extensionsonly when you need a newer feature (e.g.,Selfandoverrideif supporting < 3.11/3.12, or PEP 696default=forTypeVar/ParamSpec). Don't blanket-import fromtyping_extensions. - Always parameterize
Callable(never bareCallable). PreferCallable[..., object]; reach forCallable[..., Any]only when a caller genuinely consumes the dynamic return — if the result is just passed through (or the callable isn't even invoked),objectis stricter and equally correct. (See ParamSpec below for the signature-preserving wrapper case.) - Give any module-local global you introduce a leading underscore —
TypeVar/ParamSpec(matching the string arg:_T = TypeVar("_T"),_P = ParamSpec("_P"),_R = TypeVar("_R")),TypeAliases, helper constants, and sentinels alike. This is the prevailing torch convention for non-public names (_PoutnumbersP~6:1 in the tree). Exceptions (leave un-underscored): a name imported by other modules, listed in__all__, or used as a runtime token (e.g. an annotation-string dispatch marker). Applies only to names you add — do not rename pre-existing globals; that's an unrelated refactor outside this skill's scope. - A boolean predicate —
is_*/has_*name, takes a broad type (oftenobject), returnsbool— usually wantsTypeGuard[X](orTypeIs[X], which also narrows the negative branch).TypeGuardis intyping(>= 3.10, so import from there);TypeIsonly enteredtypingin 3.13, so import it fromtyping_extensions(>= 4.10) to stay 3.10-compatible. Anissubclass-style helper takingklass: type[_T]should returnTypeGuard[type[_T]]. Prefer an explicitisinstance(x, type)guard overtry/except TypeErroraroundissubclass()— clearer, and it lets the checker narrow. - When a return type is derived from a parameter — passthroughs/identity
functions, "return one of these args" helpers, decorators, registries keyed by
type — reach for a
TypeVar(or, for a callable arg whose signature flows through,Callable[_P, _R]withParamSpec/TypeVar) rather than widening toobject/Any. "Output type == some input type" is exactly what aTypeVarencodes;objectin /objectout discards it. Caveat: if the function transforms the value so the output type differs from the input (e.g. converts an array to an int), a singleTypeVaris wrong — name the actual domain type instead. - Class attributes assigned in
__init__should get a class-level annotation so pyrefly can see them. - Break import cycles with
if TYPE_CHECKING:— annotation-only imports go inside the guard, and usefrom __future__ import annotations(or string forward refs) so runtime imports stay lazy:from __future__ import annotations from typing import TYPE_CHECKING if TYPE_CHECKING: from torch.fx import GraphModule def transform(gm: GraphModule) -> GraphModule: ... - Never suppress the three target categories.
unannotated-return,unannotated-parameter, andimplicit-anyare always resolvable by adding an annotation;# pyrefly: ignore[<one of those>]is not an acceptable outcome. The single exception is the Backward compatibility carve-out below. - Widen, don't bail. When the right type is hard to infer, walk down this
ladder rather than reaching for an ignore:
- Most specific concrete type observable from call sites and return paths.
- A union (
X | Y),Sequence[X]-style abstract type, or a boundTypeVarfor genuinely generic functions (identity-passthrough, container helpers). object— strictest fallback that still type-checks. Forces callers to narrow before use, e.g.,def serialize(value: object) -> str:. Visually similar toAnybut stricter — pyrefly rejectsvalue.foo()without anisinstance.Any— last rung. Always preferred over a# pyrefly: ignoreon a target category, but only after rungs 1–3 fail. Be able to articulate why each earlier rung doesn't fit (e.g., "union exceeds 8 types", "no observable common bound", "callers genuinely never narrow").
- Be especially wary of
object/Anyin return position — a function usually knows more about what it produces than its callers do. A wide return is right only at a genuine boundary (it returns its input unchanged, or the value is handler/caller-defined); if the body builds a known shape, name it (a domain alias or union beatsobject). - Read at least three call sites before deciding a parameter must be
Any— don't pattern-match "looks dynamic" on the first try. - Narrow-scope
# pyrefly: ignore[...](on a non-target category) is reserved for cases where pyrefly is actually wrong about a specific local error — dynamic metaprogramming, third-party stub gaps:# pyrefly: ignore[attr-defined] result = getattr(obj, dynamic_name)() - When an inline
# pyrefly: ignore[...]would push a line past the length limit, put it on the line immediately above the flagged line rather than reaching for# fmt: skipto keep it inline — pyrefly honors a previous-line ignore. (Exception: the backward-compat carve-out below, where it must sit on thedefline.)
Backward compatibility (the one exception to never-suppress)
CRITICAL: Functions decorated with @compatibility(is_backward_compatible=True)
must NOT have their signatures changed. The backward-compat test
(test_function_back_compat) compares stringified inspect.signature against a golden
file — adding annotations (even -> None) changes that string and the test fails.
Use pyrefly ignore comments instead:
@compatibility(is_backward_compatible=True)
def my_function( # pyrefly: ignore[unannotated-return]
self,
arg1, # can't add type here either
):
...
The # pyrefly: ignore comment must be on the def line (where pyrefly reports the error),
not on the closing ).
ParamSpec for signature-preserving wrappers (decorators, functools.wraps-style
helpers). Use Callable[P, R] so the wrapped function's signature flows through
to the caller — Callable[..., Any] loses it. Skip ParamSpec if the wrapper
genuinely accepts arbitrary callables. Pair with Concatenate[X, P] when the
wrapper prepends or appends args.
from collections.abc import Callable
from typing import ParamSpec, TypeVar
_P = ParamSpec("_P")
_R = TypeVar("_R")
def log_calls(fn: Callable[_P, _R]) -> Callable[_P, _R]:
def wrapper(*args: _P.args, **kwargs: _P.kwargs) -> _R:
return fn(*args, **kwargs)
return wrapper
Step 5: Iterate
Re-run pyrefly check. New annotations often surface bad-return errors where the
function actually returns an incompatible type — fix those. Repeat until clean.
Tightening a shared helper (e.g. adding a TypeGuard or a precise return) can
make pre-existing # pyrefly: ignore comments in its callers unused. Re-check and
delete now-dead suppressions and any stale explanatory comments — don't leave them.
Step 6: Lint
Required before handing off — annotations frequently shift import order and line length:
lintrunner -a <files...>
Resolve anything lintrunner can't auto-fix manually.
Step 7: Test
Precedence when something fails: tests passing > pyrefly clean > annotation
strictness. If a freshly-added annotation breaks a test, narrow it one rung in
the discipline ladder (e.g., concrete → object, or remove an Any widening
that broke a downstream isinstance check) before reverting the file.
-
Backward-compat check. Run iff
grep -l '@compatibility(is_backward_compatible=True)' <target>returns the file — the decorator is the actual precondition for the golden file. The broader "importstorch.fx" heuristic catches half oftorch/.python -m pytest test/test_fx.py::TestFXAPIBackwardCompatibility -x -v -
Unit tests for the modified module. Search both ways before concluding no coverage exists:
# torch/foo/bar.py is usually covered by test/test_foo.py or test/test_bar.py ls test/ | grep -i <module-name> # or by import grep -rl "from torch.foo.bar import\|import torch.foo.bar" test/If both come up empty, tell the user — don't silently skip. Type changes can introduce real runtime regressions (
Optional[X]vsX,Sequencevslistwhen.appendis called, etc.).
Notes
- Forward refs in class bodies without
from __future__ import annotationsstill need string quoting:class MyClass: def __new__(cls) -> "MyClass": ... - Committing: don't commit unless the user explicitly asks (per repo CLAUDE.md). Stop and surface the diff for review when the file is clean.
Frequently asked questions about Pyrefly Type Coverage
Similar skills
React Composition Patterns
Streamline your React component architecture with proven patterns.
Pester Should Migration
Easily convert Pester v5 assertions to v6 syntax.
Radix to Base UI Migration
Seamlessly migrate React components from Radix UI to Base UI.
Migrate Next.js to Vinext
Seamlessly transition your Next.js projects to Vinext.
WinUI 3 Migration Guide
Streamline your UWP to WinUI 3 migration process.
Refactor
Enhance code maintainability without altering behavior.
