python-providers

Create, test, and package Python provider adapters under python/providers.

30.0k|4.8k|Updated Feb 23, 2024
One-click install
npx skills add https://github.com/ComposioHQ/composio --skill python-providers
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: python-providers
Source: https://github.com/ComposioHQ/composio/tree/main/.agents/skills/python-providers
Command: npx skills add https://github.com/ComposioHQ/composio --skill python-providers

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

It guides developers through creating, modifying, testing, and packaging Python provider adapter packages in the Composio monorepo without breaking public imports, type inference, or framework conventions.

Core Features & Use Cases

  • Provider Scaffolding: Create new provider packages with make create-provider name=<provider-name>, optionally with agentic support.
  • Implementation Rules: Enforces dependency placement, public import path preservation, and framework-native conventions for each provider.
  • Verification Workflow: Runs make chk, make tst, and make type_inference to validate provider changes before release.
  • Use Case: When adding a new LangChain-style provider adapter, follow the workflow to scaffold the package, register it in python/noxfile.py type inference lists, and verify with the standard make targets.

Quick Start

Ask the assistant to create a new Python provider package named after your framework and run the standard checks for it.

Frequently Asked Questions about python-providers

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create a new Python provider package in Composio?

Run `make create-provider name=<provider-name>` from the python/ directory, adding `agentic=true` for agentic providers. The new package is scaffolded under python/providers/.

How do I test changes to a Python provider adapter?

Run `make chk`, `make tst`, and `make type_inference` from the python/ directory. For faster iteration, use pytest markers or direct test paths matching the specific provider.

When do I need to update noxfile.py for a new provider?

New or renamed provider packages usually need explicit entries in python/noxfile.py's type_inference provider install list and checked-file list so type inference verification covers them.

Should provider dependencies go in the core SDK or the provider package?

Keep provider-specific dependencies in the provider package's own metadata unless shared tooling needs them. This keeps the core SDK lean and preserves framework-native conventions.

When should I use python-sdk instead of the python-providers skill?

Use python-providers only for work on provider adapter packages under python/providers. For core SDK changes, use the python-sdk skill instead, as the provider workflow rules do not apply there.