cross-sdk-parity

Aligns TypeScript and Python SDK behavior, generated client pins, and public API naming.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Maintaining two SDKs in different languages often leads to drift: mismatched public APIs, divergent generated client versions, and inconsistent docs examples. This Skill provides a structured workflow to keep the TypeScript and Python Composio SDKs behaviorally aligned whenever a change affects both.

Core Features & Use Cases

  • Public Contract Comparison: Check tools, sessions, connected accounts, auth configs, provider wrappers, error shapes, and docs examples across both SDKs.
  • Generated Client Bump Workflow: Step-by-step commands for updating @composio/client pins in pnpm-workspace.yaml and composio-client in pyproject.toml, setup.py, and uv.lock.
  • Naming Conventions: Enforces camelCase for TypeScript and snake_case for Python while preserving backend wire names in generated clients.
  • Use Case: When a backend API contract changes, use this Skill to update the generated client pins in both SDKs, verify naming conventions, and run import/typecheck checks to confirm parity.

Quick Start

Ask the agent to verify that the TypeScript and Python SDKs expose equivalent behavior for a recent API change and to update the generated client pins in both packages.

Frequently Asked Questions about cross-sdk-parity

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

FAQPage Schema
How do I keep TypeScript and Python SDKs in sync?

Compare the public contract across both SDKs: tools, sessions, connected accounts, auth configs, provider wrappers, and error shapes. Then update generated client pins in each package manager and run import or typecheck checks on both sides.

How do I bump the generated client version in a pnpm monorepo?

Verify the new version with npm view @composio/client version, update the catalog pin in pnpm-workspace.yaml, refresh pnpm-lock.yaml with pnpm install --lockfile-only, and add changesets for affected published packages.

How do I update the composio-client dependency in Python?

Check available versions with pip index versions composio-client, update python/pyproject.toml and python/setup.py, then refresh the root uv.lock with uv lock --upgrade-package composio-client and run an import check.

What naming conventions should cross-language SDKs follow?

TypeScript public APIs use camelCase while Python public APIs use snake_case. Backend wire names are preserved only where generated clients require them, keeping each SDK idiomatic to its language.

When should I not use a cross-SDK parity workflow?

Skip it for single-language internal-only changes that do not affect the public contract, generated clients, or docs examples. Parity checks add overhead that is unnecessary when only one SDK's internals change.