cross-sdk-parity

Keep TypeScript and Python SDK behavior, generated client usage, public API naming, and docs examples aligned. Use when a change affects both SDKs, when generated client pins move, when comparing TS/Python behavior, or when a backend API contract changed. Do not use for single-language internal-only changes.

Quality

81%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

65%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

An extremely lean body that gets structure right — a clean overview delegating to a real, one-level-deep reference — but it delegates almost everything: no inline steps, commands, or validation checkpoints, leaving the body itself thin on actionability and workflow sequencing.

Suggestions

Add a short inline quick-start (3-4 bullet steps or one concrete command per SDK, e.g., the pin-check commands) so the body is actionable without opening the reference.

Surface the workflow order explicitly — when to compare the public contract, when to bump pins, and the verify-before-proceeding checkpoint — rather than leaving all sequencing inside the reference file.

Optionally inline the naming rule (camelCase for TypeScript, snake_case for Python) as a one-line preview of what the reference covers.

Dimension	Reasoning	Score
Conciseness	The body is two lean sentences with zero padding and no explanation of concepts Claude already knows; every token earns its place. Matches the 'lean and efficient' anchor.	5 / 5
Actionability	"Read `references/parity-workflow.md` before changing shared SDK behavior or generated client pins" is a high-level pointer with no concrete steps, commands, or examples in the body itself — all executable content lives one file away. Matches 'minimal concrete guidance; missing the specific steps'; not 3 because no key execution details are present at all.	2 / 5
Workflow Clarity	The underlying task is multi-step (contract comparison, per-language client bumps, naming rules, verification) but the body sequences none of it and includes no validation checkpoints; the reference's verification step is loosely stated and not wired as an explicit step-gate. Not 2 because the single directive given is unambiguous and a coherent workflow does exist one level deep; not 4 because checkpoints are missing rather than minor-gapped.	3 / 5
Progressive Disclosure	The body is a clear overview with a well-signaled, correctly-pathed, one-level-deep reference; the referenced file references/parity-workflow.md exists on disk and holds the detailed material, so content is appropriately split and navigation is trivial. Matches the 5 anchor.	5 / 5
	Total	15 / 20 Passed

Description

87%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description: concrete what, explicit and varied when-triggers, third-person imperative voice, and a useful negative boundary clause. Its only weaknesses are mild — the core verb is generic and a few natural synonyms are absent.

Suggestions

Replace or supplement the generic verb 'Keep ... aligned' with a more concrete operation, e.g., 'Audit and update both SDKs so behavior, generated client usage, naming, and docs examples stay aligned'.

Add a couple of natural synonyms users might actually say, such as 'parity', 'both SDKs', or the package names involved, to broaden trigger matching.

Dimension	Reasoning	Score
Specificity	"Keep TypeScript and Python SDK behavior, generated client usage, public API naming, and docs examples aligned" names the domain and several specific action areas, matching the 'several specific actions; minor gaps' anchor. Not 5 because the governing verb is generic ('keep aligned') and concrete operations like pin bumps or verification are absent; not 3 because coverage exceeds 1-2 actions.	4 / 5
Completeness	Explicitly answers both: what ("Keep TypeScript and Python SDK behavior, generated client usage, public API naming, and docs examples aligned") and when ("Use when a change affects both SDKs, when generated client pins move, when comparing TS/Python behavior, or when a backend API contract changed") with concrete trigger phrases, plus a negative boundary clause. Matches the 5 anchor exactly.	5 / 5
Trigger Term Quality	Triggers include natural developer phrasings — "a change affects both SDKs", "generated client pins move", "comparing TS/Python behavior", "a backend API contract changed" — with a TS/Python abbreviation variation. Good keyword coverage, but a few natural terms users might say (e.g., 'parity', 'both languages', package names) are missing, so not 5.	4 / 5
Distinctiveness Conflict Risk	A clear niche (cross-SDK TS/Python parity) with distinct triggers and an explicit exclusion ("Do not use for single-language internal-only changes") that minimizes conflict with single-language or general SDK skills. Not 4: overlap risk is negligible.	5 / 5
	Total	18 / 20 Passed

Validation

100%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: ComposioHQ/composio
Path: .agents/skills/cross-sdk-parity/SKILL.md
Commit: 98b10d7

Reviewed: 3 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.