agentleFS
CreativeActtechCreativeActtech/llm-skills/skills/example-skill/python-type-hinter/SKILL.md

python-type-hinter

Skill2 starsChanged 7 months agoMITView on GitHub

Adds PEP 484 type hints to existing Python code. Use when requesting "add type hints", "annotate this function", or "improve typing coverage". Do NOT use for runtime type checking, generating stubs for C extensions, or converting to static types (e.g., mypyc).

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 5 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Do NOT use when the user explicitly wants to keep dynamic typing or is targeting Python < 3.5

    line 21
  2. Very specific:

    Do NOT use for generating .pyi stub files or runtime isinstance checks

    line 22
  3. Very specific:

    IF variable is assigned a literal (42, "text", [1,2]) → use literal type.

    line 33
  4. Distinctive:

    IF function always returns same type → annotate return type.

    line 34
  5. Very specific:

    IF function may return None or another type → use Optional[Type] or Union.

    line 35
  6. Distinctive:

    IF parameter has default value → infer from default.

    line 36
  7. Very specific:

    IF external library call (e.g., requests.get()) → use common known return types (Response).

    line 37
  8. Distinctive:

    If the code already has complete type hints, respond with:

    line 83
  9. Distinctive:

    If type inference fails for a specific block, insert # TODO: Type hint - unknown structure and note in the report.

    line 93

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Python Type Hinter

Intelligent inference and insertion of type annotations based on variable usage, return statements, and common library types.

🎯 When to Use

  • User provides untyped Python code and asks to "add type hints" or "make it mypy‑ready"
  • Code uses complex data structures (dict, list, custom classes) where types are ambiguous
  • User wants to improve IDE autocompletion or documentation
  • Do NOT use when the user explicitly wants to keep dynamic typing or is targeting Python < 3.5
  • Do NOT use for generating .pyi stub files or runtime isinstance checks

🧠 Core Workflow

Step 1 — Analyze Code Context Parse AST to identify functions, variables, and return statements. Detect patterns:

  • if isinstance(x, int): → narrow type to int
  • return [] → List[Any] or attempt to infer element type
  • self.attr = value → infer instance attribute type

Step 2 — Infer Types Heuristically

  • IF variable is assigned a literal (42, "text", [1,2]) → use literal type.
  • IF function always returns same type → annotate return type.
  • IF function may return None or another type → use Optional[Type] or Union.
  • IF parameter has default value → infer from default.
  • IF external library call (e.g., requests.get()) → use common known return types (Response).

Step 3 — Add Imports Insert from typing import List, Dict, Optional, Union, ... as needed. Avoid over‑importing.

Step 4 — Annotate in Place Produce the same code with inline type hints added. Preserve original runtime behavior. Use comments for complex cases (e.g., # type: ignore when inference is uncertain).

Step 5 — Validation Recommendation Suggest running mypy --strict on the annotated code and provide a diff of changes.

📋 Output Format

Section 1 — Type Hint Report

{
  "status": "success",
  "functions_annotated": 4,
  "variables_annotated": 12,
  "imports_added": ["List", "Optional"],
  "confidence_issues": ["Return type ambiguous in `process_data` → Any"]
}

Section 2 — Annotated Code

from typing import List, Optional

def greet(name: str) -> str:
    return f"Hello, {name}"

def process_items(items: List[int], factor: Optional[float] = None) -> List[float]:
    if factor is None:
        factor = 1.0
    return [i * factor for i in items]

Section 3 — Suggested mypy Command

mypy --strict annotated_module.py

⚠️ Fallback Behavior

If the code already has complete type hints, respond with:

{
  "status": "partial",
  "message": "All functions and variables already have PEP 484 annotations. No changes made.",
  "suggestion": "Consider enabling `disallow_untyped_defs = True` in mypy config for stricter enforcement."
}

If type inference fails for a specific block, insert # TODO: Type hint - unknown structure and note in the report.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.