api-connector-builder

Builds API integrations that follow a codebase's existing connector conventions.

Updated Aug 3, 2026
One-click install
npx skills add https://github.com/m-de-graaff/skills --skill api-connector-builder-m-de-graaff
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: api-connector-builder
Source: https://github.com/m-de-graaff/skills/tree/main/skills/api-connector-builder
Command: npx skills add https://github.com/m-de-graaff/skills --skill api-connector-builder-m-de-graaff

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Adding a new API integration to a codebase that already has connectors often produces a foreign architecture: vendor SDK conventions, mismatched error handling, and missing registration or tests. This Skill ensures a new connector mirrors the repo's established patterns so it stays maintainable. ## Core Features & Use Cases - Pattern Discovery: Inspects at least two existing connectors to map file layout, config, auth, transport, error taxonomy, registration, and test fixtures before writing code. - Surface Narrowing: Defines only the auth flows, entities, operations, pagination, and rate limits the repo actually needs instead of the vendor's full API surface. - Layered Construction: Builds config, client/transport, mapping, entrypoint, registration, and tests in the repo's own layers, with a checklist covering secrets, error types, retries, and discovery wiring. - Use Case: When asked to "add a Slack provider" or "build a Jira connector", the Skill guides the AI to copy the newest existing integration's shape, map vendor fields to domain types, and ship tests mirroring existing fixtures. ## Quick Start Ask the AI to add a new integration for a third-party API to this repository following the existing connector patterns.

Frequently Asked Questions about api-connector-builder

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

FAQPage Schema
How do I add a new API integration to an existing codebase?▼

Inspect at least two existing connectors to learn the repo's file layout, config, auth, transport, and error conventions, then build the new integration in those same layers. Define only the operations the repo actually needs rather than the vendor's full API surface.

Should I start from the vendor SDK quickstart when building a connector?▼

No. Vendor quickstarts pull in their own config, logging, and error conventions that conflict with the repo's architecture. Write against the repo's existing HTTP client and patterns instead, even if it means a few dozen extra lines.

What layers should an API connector include?▼

Typical layers are config/schema validation, client/transport with retries and pagination, a mapping layer converting vendor shapes to domain types, the connector entrypoint, registration wiring, and tests mirroring existing fixtures. The mapping layer is most often skipped and most often regretted.

What if two existing connectors in the repo follow different patterns?▼

Ask which pattern is current rather than picking one yourself. Copying the older connector propagates a pattern the team already decided to leave behind, so confirm before modeling the new integration on it.

When should I not use this connector-building approach?▼

This Skill does not design the upstream API itself, cover backend server internals, or decide whether the integration should exist at all. Use it only when the decision to integrate is made and the codebase already has integrations to model against.