
Python Development
Match Microsoft Agent Framework Python conventions—headers, typing, parameters, and lint-friendly patterns—when editing code under python/.
Overview
Python Development is an agent skill for the Build phase that enforces Agent Framework Python coding standards when writing or modifying files in the python/ directory.
Install
npx skills add https://github.com/microsoft/agent-framework --skill python-developmentWhat is this skill?
- Mandatory Microsoft copyright header on every .py file
- Modern typing: Type | None, postponed annotations, TypeVar suffix T, Mapping over MutableMapping
- Keyword-only optional parameters after * with string Literal overrides for modes
- Guidance on specific type: ignore comments for mypy and pyright
- Parameter layout rules: up to three positional args, avoid **kwargs and builtin shadowing
- Every .py file must start with the Microsoft copyright header line
Adoption & trust: 51 installs on skills.sh; 11.2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent-generated Python for Agent Framework drifts from Microsoft typing, header, and API conventions, creating noisy mypy or pyright failures in review.
Who is it for?
Contributors or indie maintainers patching Microsoft Agent Framework Python with Claude Code, Cursor, or Codex and wanting repo-native style on the first pass.
Skip if: Greenfield Python apps outside agent-framework, non-Python languages, or quick scripts where corporate header and strict typing rules do not apply.
When should I use this skill?
Writing or modifying Python source files in the python/ directory of the Agent Framework repository.
What do I get? / Deliverables
New or edited .py files follow framework headers, annotation rules, and parameter patterns so they align with upstream contribution expectations.
- Python modules conforming to Agent Framework header and typing rules
- APIs using keyword-only optional parameters and string mode overrides where specified
Recommended Skills
Journey fit
Repository coding standards apply while you implement agent runtime code, not during idea research or launch SEO. The skill explicitly targets Python source in the Agent Framework python/ tree—agent tooling implementation, not generic frontend or docs-only edits.
How it compares
Repo-specific style guide skill—not a generic PEP-8 linter pack or runtime debugging workflow.
Common Questions / FAQ
Who is python-development for?
Developers changing Python in the Microsoft Agent Framework repository who need agent-assisted edits to match upstream conventions.
When should I use python-development?
During Build agent-tooling whenever you add modules, fix types, or refactor handlers under python/ before opening a PR.
Is python-development safe to install?
It is documentation-only standards guidance; still review the Security Audits panel on this page before trusting any third-party skill package.
SKILL.md
READMESKILL.md - Python Development
# Python Development Standards ## File Header Every `.py` file must start with: ```python # Copyright (c) Microsoft. All rights reserved. ``` ## Type Annotations - Always specify return types and parameter types - Use `Type | None` instead of `Optional[Type]` - Use `from __future__ import annotations` to enable postponed evaluation - Use suffix `T` for TypeVar names: `ChatResponseT = TypeVar("ChatResponseT", bound=ChatResponse)` - Use `Mapping` instead of `MutableMapping` for read-only input parameters - Prefer `# type: ignore[...]` over unnecessary casts, or `isinstance` checks, when these are internally called and executed methods But make sure the ignore is specific for both mypy and pyright so that we don't miss other mistakes ## Function Parameters - Positional parameters: up to 3 fully expected parameters - Use keyword-only arguments (after `*`) for optional parameters - Provide string-based overrides to avoid requiring extra imports: ```python def create_agent(name: str, tool_mode: Literal['auto', 'required', 'none'] | ChatToolMode) -> Agent: if isinstance(tool_mode, str): tool_mode = ChatToolMode(tool_mode) ``` - Avoid shadowing built-ins (use `next_handler` instead of `next`) - Avoid `**kwargs` unless needed for subclass extensibility; prefer named parameters ## Docstrings Use Google-style docstrings for all public APIs: ```python def equal(arg1: str, arg2: str) -> bool: """Compares two strings and returns True if they are the same. Args: arg1: The first string to compare. arg2: The second string to compare. Returns: True if the strings are the same, False otherwise. Raises: ValueError: If one of the strings is empty. """ ``` - Always document Agent Framework specific exceptions - Explicitly use `Keyword Args` when applicable - Only document standard Python exceptions when the condition is non-obvious ## Import Structure ```python # Core from agent_framework import Agent, Message, tool # Components from agent_framework.observability import enable_sensitive_telemetry # Connectors (lazy-loaded) from agent_framework.openai import OpenAIChatClient from agent_framework.foundry import FoundryChatClient ``` ## Public API and Exports In `__init__.py` files that define package-level public APIs, use direct re-export imports plus an explicit `__all__`. Avoid identity aliases like `from ._agents import Agent as Agent`, and avoid `from module import *`. Do not define `__all__` in internal non-`__init__.py` modules. Exception: modules intentionally exposed as a public import surface (for example, `agent_framework.observability`) should define `__all__`. ```python __all__ = ["Agent", "Message", "ChatResponse"] from ._agents import Agent from ._types import Message, ChatResponse ``` ## Performance Guidelines - Cache expensive computations (e.g., JSON schema generation) - Prefer `match/case` on `.type` attribute over `isinstance()` in hot paths - Avoid redundant serialization — compute once, reuse ## Style - Line length: 120 characters - Format only files you changed, not the entire codebase - Prefer attributes over inheritance when parameters are mostly the same - Async by default — assume everything is asynchronous ## Naming Conventions for Connectors - `_prepare_<object>_for_<purpose>` for methods that prepare data for external services - `_parse_<object>_from_<source>` for methods that process data from external services