home / skills / a5c-ai / babysitter / python-sdk-specialist

This skill helps you design Pythonic SDKs with async support and strong type hints, improving reliability and developer productivity.

npx playbooks add skill a5c-ai/babysitter --skill python-sdk-specialist

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

Files (2)
SKILL.md
2.0 KB
---
name: python-sdk-specialist
description: Python SDK development with async support and type hints
allowed-tools:
  - Read
  - Write
  - Edit
  - Glob
  - Grep
  - Bash
---

# Python SDK Specialist Skill

## Overview

This skill specializes in developing Pythonic SDKs with full type hint support, async/await capabilities, and modern Python best practices for Python 3.8+ compatibility.

## Capabilities

- Design Pythonic SDK architecture following PEP guidelines
- Implement async/await with aiohttp, httpx, or asyncio
- Configure comprehensive type hints with mypy validation
- Support Python 3.8+ with proper compatibility handling
- Implement context managers for resource management
- Design intuitive API surfaces following Python conventions
- Configure packaging for PyPI distribution
- Implement proper logging and debugging support

## Target Processes

- Multi-Language SDK Strategy
- SDK Architecture Design
- SDK Testing Strategy

## Integration Points

- PyPI package registry
- pytest for testing
- mypy for type checking
- httpx/aiohttp for HTTP clients
- pydantic for data validation
- poetry/setuptools for packaging

## Input Requirements

- API specification (OpenAPI, GraphQL, or custom)
- Target Python version range
- Async requirements
- Type strictness level
- Packaging preferences (poetry vs setuptools)

## Output Artifacts

- Python SDK package source code
- Type stub files (.pyi) if needed
- pytest test suite
- pyproject.toml configuration
- Documentation (Sphinx-ready)
- Example scripts

## Usage Example

```yaml
skill:
  name: python-sdk-specialist
  context:
    apiSpec: ./openapi.yaml
    pythonVersion: ">=3.8"
    asyncSupport: true
    typeHints: strict
    httpClient: httpx
    packageManager: poetry
```

## Best Practices

1. Follow PEP 8 style guide
2. Use type hints throughout (PEP 484, 585)
3. Implement both sync and async interfaces
4. Use context managers for connections
5. Provide comprehensive docstrings (Google style)
6. Support optional dependencies properly

Overview

This skill delivers Python SDK design and implementation focused on type hints, async support, and modern Python best practices for Python 3.8+. I build deterministic, well-tested SDKs with clear packaging and documentation to accelerate API consumption and maintainability.

How this skill works

I take an API specification (OpenAPI, GraphQL, or custom) and generate a Pythonic client surface with both sync and async interfaces, using httpx/aiohttp or asyncio as requested. The output includes typed models, mypy-checked code, pytest tests, packaging metadata, and Sphinx-ready docs so the SDK can be published and maintained reproducibly.

When to use it

  • You need a maintainable Python SDK for an existing API with async/await support.
  • You want strict type checking and mypy validation across the client surface.
  • You need both sync and async interfaces for diverse consumer environments.
  • You plan to publish the package to PyPI with production-ready packaging.
  • You require test coverage and documented examples for developer adoption.

Best practices

  • Follow PEP 8 and PEP 484/585 conventions for readable, typed code.
  • Provide both sync and async clients to maximize compatibility.
  • Use context managers to manage connections and resources safely.
  • Validate models with pydantic or similar and include mypy CI checks.
  • Ship clear docstrings, examples, and a Sphinx documentation site.

Example use cases

  • Generate a Python SDK from an OpenAPI spec with strict type hints and publish to PyPI using poetry.
  • Build an async-first client using httpx for high-concurrency microservices.
  • Add synchronous wrappers for legacy codebases while keeping an async core.
  • Create a pytest suite and CI pipeline to enforce type and test coverage.
  • Produce .pyi stubs and Sphinx docs for a commercial API developer portal.

FAQ

Do you support both sync and async APIs?

Yes. I implement an async core and provide optional synchronous wrappers so consumers can choose either model.

Which HTTP clients do you use?

I commonly use httpx for async-first implementations and aiohttp when required; asyncio primitives are used where appropriate.