api-connector-builder

Builds API connectors matching a repository's existing integration patterns and conventions.

Updated Mar 18, 2026
One-click install
npx skills add https://github.com/freedom909/real-estate-saas --skill api-connector-builder-freedom909
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: api-connector-builder
Source: https://github.com/freedom909/real-estate-saas/tree/main/.trae/skills/api-connector-builder
Command: npx skills add https://github.com/freedom909/real-estate-saas --skill api-connector-builder-freedom909

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Adding a new API integration often leads to inconsistent architecture when developers copy vendor docs or invent new patterns instead of following the host repository's established connector style, resulting in fragmented codebases that are hard to maintain. ## Core Features & Use Cases - Pattern Matching: Inspects at least two existing in-repo connectors to map file layout, config schema, auth model, error handling, and test style before writing any code. - Repo-Native Layering: Guides building the integration in the repository's own slices: config/schema, client/transport, mapping layer, provider entrypoint, registration, and tests. - Guardrails Against Drift: Prevents inventing a second integration architecture, cargo-culting outdated connectors, or stopping at transport code without registry wiring and docs. - Use Case: When asked to "add a Slack provider following the existing pattern," the Skill first studies current providers, then produces a connector that looks native to the codebase, complete with config validation, retry/pagination conventions, and matching tests. ## Quick Start Ask the AI to build a new Jira connector for this project following the existing integration pattern.

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?▼

Start by inspecting at least two existing connectors in the repository to map their file layout, config model, auth flow, and test conventions. Then build the new integration in those same layers rather than copying vendor documentation examples.

How to build a connector that matches an existing provider pattern?▼

Identify the repo's current pattern first: provider-style, connector-style, or TypeScript plugin-style. Replicate its abstraction boundaries, retry and pagination conventions, and registry hooks so the new connector looks native to the codebase.

What should a complete API connector include besides the HTTP client?▼

A complete connector includes config validation, explicit auth and error handling, a mapping layer, registration or discovery wiring, and tests mirroring the host repo's style. Transport code alone leaves the integration incomplete.

When should I not follow an old connector pattern in a repo?▼

Do not cargo-cult old connectors when the repository has moved to a newer current pattern. Compare multiple existing integrations to identify which style is actively maintained before modeling your new connector on it.

Why do new integrations cause inconsistent architecture in codebases?▼

Inconsistency happens when developers start from vendor docs alone or invent a second integration architecture instead of following the repo's established pattern. Matching existing connectors keeps config, auth, and error handling uniform.