Api connector builder

Skill Krishnendu409/EVERYTHING-CLAUDE-FREE-VERSION/skills/api-connector-builder

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.From its SKILL.md

Install

npx -y skills add Krishnendu409/EVERYTHING-CLAUDE-FREE-VERSION --skill api-connector-builder

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.6 KB, 545 tokens by cl100k_base, as published. Nobody here has run it

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