home / skills / gigaverse-app / skillet / type-checking

This skill helps you adopt type hints and fix type errors with Pyright or Basedpyright without changing runtime behavior.

npx playbooks add skill gigaverse-app/skillet --skill type-checking

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

Files (3)
SKILL.md
2.6 KB
---
name: type-checking
description: Use when adding type hints, fixing type checker errors, expanding type coverage, or when user mentions "type check", "pyright", "basedpyright", "mypy", "type hints", "type errors", "type annotations", "typing", "Any type", "weak types".
---

# Type Checking with Pyright/Basedpyright

Use pyright or basedpyright for gradual type checking adoption.

## Core Principles

1. **Minimize Logic Changes**: Type checking should NOT change runtime behavior
2. **Test After Changes**: Always run tests after adding type hints
3. **Hunt Down Root Causes**: Never use `# type: ignore` as first resort

## Quick Start

When fixing type errors:

```bash
# 1. Run type checker
pyright <file-or-directory>
# or
basedpyright <file-or-directory>

# 2. Fix errors (see patterns.md for common fixes)

# 3. Verify no behavior changes
git diff main
pytest tests/
```

## Fix Priority Order

1. **Add proper type annotations** (Optional, specific types)
2. **Fix decorator return types**
3. **Use `cast()`** for runtime-compatible but statically unverifiable types
4. **Last resort: `# type: ignore`** only for legitimate cases

## Common Quick Fixes

### Field Defaults
```python
# Use keyword syntax
role: Role = Field(default=Role.MEMBER, description="...")

# Positional default - avoid
role: Role = Field(Role.MEMBER, description="...")
```

### Optional Parameters
```python
# Correct
def my_function(channel_id: Optional[str] = None):

# Wrong
def my_function(channel_id: str = None):
```

### Weak Types - NEVER Use
```python
# NEVER
items: list[Any]
data: dict
result: Any

# ALWAYS use specific types
items: list[DataItem]
data: dict[str, ProcessedResult]
result: SpecificType | OtherType
```

### Prefer cast() Over type: ignore
```python
from typing import cast

# Preferred
typed_results = cast(list[ResultProtocol], results)
selected = select_by_score(typed_results)

# Less clear
selected = select_by_score(results)  # type: ignore[arg-type]
```

## When to Use type: ignore

Only for:
1. Function attributes: `func._attr = val  # type: ignore[attr-defined]`
2. Dynamic/runtime attributes not in type system
3. External library quirks (protobuf, webhooks)
4. Legacy patterns requiring significant refactoring

DO NOT use for simple fixes (add Optional, fix return types, add imports).

## Reference Files

For detailed patterns and procedures:
- [references/patterns.md](references/patterns.md) - Common Pydantic + Pyright patterns with examples
- [references/expanding-coverage.md](references/expanding-coverage.md) - How to add new modules to type checking

**Remember**: Always verify changes with `git diff main` before committing.

Overview

This skill helps developers add and repair Python type hints using Pyright or BasedPyright for gradual type checking. It emphasizes non-invasive fixes, prioritizes concrete typing over ignores, and checks that type changes do not alter runtime behavior. Use it to expand type coverage, resolve type checker errors, and improve long-term code quality.

How this skill works

Run the type checker against a file or directory, inspect reported errors, and apply fixes following a prioritized sequence: add precise annotations, correct decorator and return types, use cast() when static typing cannot capture runtime shapes, and only then add type: ignore for exceptional cases. After fixes, run tests and review diffs to ensure no behavioral changes.

When to use it

  • When Pyright/BasedPyright or mypy reports type errors you want to resolve
  • When introducing or expanding type hints across a module or package
  • When a function or decorator has incorrect or missing return types
  • When reducing uses of Any, weak container types, or raw dict/list annotations
  • When merging changes that require type-safety verification before commit

Best practices

  • Minimize logic changes: type fixes should not change runtime behavior
  • Run tests and git diff main after typing changes to detect regressions
  • Prefer specific types over Any or unparameterized containers
  • Use typing.cast() for runtime-compatible-but-statically-opaque values
  • Avoid # type: ignore unless the issue is a runtime dynamic attribute or external library quirk
  • Fix root causes first (Optional, return types, imports) before ignoring errors

Example use cases

  • Fixing a Pyright error where a parameter is annotated as str but None is passed — change to Optional[str]
  • Annotating Pydantic Field defaults correctly to satisfy the type checker without changing behavior
  • Replacing list[Any] or dict with concrete generic types like list[DataItem] or dict[str, Result]
  • Using cast() to tell the type checker a runtime-validated list matches a protocol before calling typed functions
  • Applying type: ignore[attr-defined] for a dynamically attached function attribute from a third-party runtime hook

FAQ

When is it acceptable to use # type: ignore?

Only for dynamic or runtime attributes, external library quirks, or legacy patterns needing large refactors. Do not use it for simple fixes like adding Optional or correcting return types.

Should I change code behavior to satisfy the type checker?

No. Type changes should not alter runtime behavior. If a fix would change behavior, prefer annotations or cast() and add tests before committing.