api-connector-builder

Use it when:: You're adding one more integration, such as a Jira or Slack provider, to a repo that already has several.
It does:: Studies at least two existing connectors first, narrows the target API to what the repo needs, then builds it in the same layers.
You get:: A connector that looks native to the codebase, with config validation, explicit auth and errors, registry wiring, tests and docs.
Unlike starting from docs:: This one starts from the repo's current pattern, not the vendor's docs or a generic HTTP client.

TL;DR

A short workflow for integrations that should look like they were always there. It first inspects at least two existing connectors or providers and maps their file layout, abstraction boundaries, config model, retry and pagination conventions, registry hooks and test fixtures. It then narrows the new integration to what the repo needs: the auth flow, key entities, core read and write operations, pagination and rate limits, and webhooks or polling. It builds in the repo's own layers, typically config, client, mapping, entry point, registration and tests, and finishes against a checklist: it matches an existing pattern, validates config, handles auth and errors explicitly, follows retry norms, completes registry wiring, mirrors the test style and updates docs where the repo expects it. Its guardrails: don't invent a second architecture, don't stop at transport code, and don't copy an old connector when a newer pattern exists. Reference shapes cover Python provider and connector layouts and a TypeScript plugin layout.

Summarizes the skill at d2ef268.

npx skills add https://github.com/affaan-m/ecc --skill api-connector-builder

skills.sh page Source on GitHub All skills from affaan-m/ecc

Total Downloads: 5,400 on skills.sh, Nov 9, 2026
Repo stars: 299,776 affaan-m/ecc
First seen: May 19, 2026 on skills.sh

Weekly Downloads

443

+74% over the 8 weeks to Nov 9

Weekly values

Week to	Installs
Sep 21	255
Sep 28	162
Oct 5	139
Oct 12	233
Oct 19	411
Oct 26	404
Nov 2	470
Nov 9	443

Category	category:engineering category:software-engineering Test-first work, implementation from specs, git hygiene and scope control. Everything for building software: planning, coding, debugging, design, frameworks, cloud, agents and skills.
Type	type:workflow A multi-step process the agent follows: interview, debug, run a TDD loop, review.
Effect	effect:local Its own steps create or change files, git state or local tools.
Needs	needs:none Instructions only. Works in any agent that supports skills.
Publisher	by:community Everyone else. Unverified vendor claims default to community.
Topics	implementation backend code-quality

SKILL.md

From affaan-m/ecc at d2ef268. Checked daily, last changed Nov 6, 2026.

Frontmatter

name: api-connector-builder
description: Build a new API connector or provider by matching the target repo's existing integration pattern exactly. Use when adding one more integration without inventing a second architecture.
metadata:
  version: "1.0.0"
  origin: ECC direct-port adaptation

API Connector Builder

Use this when the job is to add a repo-native integration surface, not just a generic HTTP client.

The point is to match the host repository's pattern:

connector layout
config schema
auth model
error handling
test style
registration/discovery wiring

When to Use

"Build a Jira connector for this project"
"Add a Slack provider following the existing pattern"
"Create a new integration for this API"
"Build a plugin that matches the repo's connector style"

Guardrails

do not invent a new integration architecture when the repo already has one
do not start from vendor docs alone; start from existing in-repo connectors first
do not stop at transport code if the repo expects registry wiring, tests, and docs
do not cargo-cult old connectors if the repo has a newer current pattern

Workflow

1. Learn the house style

Inspect at least 2 existing connectors/providers and map:

file layout
abstraction boundaries
config model
retry / pagination conventions
registry hooks
test fixtures and naming

2. Narrow the target integration

Define only the surface the repo actually needs:

auth flow
key entities
core read/write operations
pagination and rate limits
webhook or polling model

3. Build in repo-native layers

Typical slices:

config/schema
client/transport
mapping layer
connector/provider entrypoint
registration
tests

4. Validate against the source pattern

The new connector should look obvious in the codebase, not imported from a different ecosystem.

Reference Shapes

Provider-style

providers/
  existing_provider/
    __init__.py
    provider.py
    config.py

Connector-style

integrations/
  existing/
    client.py
    models.py
    connector.py

TypeScript plugin-style

src/integrations/
  existing/
    index.ts
    client.ts
    types.ts
    test.ts

Quality Checklist

[ ] matches an existing in-repo integration pattern
[ ] config validation exists
[ ] auth and error handling are explicit
[ ] pagination/retry behavior follows repo norms
[ ] registry/discovery wiring is complete
[ ] tests mirror the host repo's style
[ ] docs/examples are updated if expected by the repo

Related Skills

backend-patterns
mcp-server-patterns
github-ops