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).
In this repository20 other files it gives its agents.
- api-design-standardizerSkill
- api-documentation-generatorSkill
- cloud-infrastructure-architectSkill
- cobol-to-javaSkill
- code-reviewSkill
- compliance-policy-auditorSkill
- database-performance-auditorSkill
- data-cleanupSkill
- incident-post-mortem-generatorSkill
- kaggle-notebook-generatorSkill
- meeting-transcriberSkill
- pdf-extractSkill
- python-structure-generatorSkill
- refactor-simplifySkill
- github-repo-structure-builderSkill
- security-vulnerability-scannerSkill
- sql-query-optimizerSkill
- unit-test-generatorSkill
- user-story-generatorSkill
- web-researchSkill
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
- Distinctive: line 21
Do NOT use when the user explicitly wants to keep dynamic typing or is targeting Python < 3.5
- Very specific: line 22
Do NOT use for generating .pyi stub files or runtime isinstance checks
- Very specific: line 33
IF variable is assigned a literal (42, "text", [1,2]) → use literal type.
- Distinctive: line 34
IF function always returns same type → annotate return type.
- Very specific: line 35
IF function may return None or another type → use Optional[Type] or Union.
- Distinctive: line 36
IF parameter has default value → infer from default.
- Very specific: line 37
IF external library call (e.g., requests.get()) → use common known return types (Response).
- Distinctive: line 83
If the code already has complete type hints, respond with:
- Distinctive: line 93
If type inference fails for a specific block, insert # TODO: Type hint - unknown structure and note in the report.
≈ “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.
Files
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
.pyistub files or runtimeisinstancechecks
🧠 Core Workflow
Step 1 — Analyze Code Context Parse AST to identify functions, variables, and return statements. Detect patterns:
if isinstance(x, int):→ narrow type tointreturn []→List[Any]or attempt to infer element typeself.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
Noneor another type → useOptional[Type]orUnion. - 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.
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
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.

