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

backend-patterns
mcp-server-patterns
github-ops

Files1

1 files · 1.0 KB

Select a file to preview

Overall Score

76/100

Grade

B

Good

Safety

85

Quality

72

Clarity

78

Completeness

68

Summary

The API Connector Builder skill guides agents to add new API integrations to a codebase by studying and replicating the existing integration architecture. It emphasizes learning the repo's established patterns (file layout, config schema, auth model, testing style) before building, ensuring consistency across connectors rather than inventing novel architectures.

Detected Capabilities

repository analysis (inspect existing connectors)file structure analysiscode pattern matchingfile write (creating connector code)test writing

Trigger Keywords

Phrases that MCP clients use to match this skill to user intent.

add api connectorbuild integrationnew provider patternmatch existing connectorintegrate external api

Use Cases

Add a new Jira, Slack, or external API connector following the repo's established pattern
Build a provider or integration that mirrors existing in-repo connectors without duplicating architecture
Create plugin-style integrations (Python providers, TypeScript plugins) that fit the host repository's conventions
Ensure new connectors include config validation, auth handling, pagination, registry wiring, and tests matching repo norms

Quality Notes

Strengths: Clear guardrails explicitly reject anti-patterns (inventing new architectures, cargo-cult copying, incomplete implementation)
Strengths: Workflow is well-sequenced (learn → narrow → build → validate) with concrete steps
Strengths: Reference shapes provide concrete file layout examples for three common integration patterns
Strengths: Quality checklist ensures completeness (config, auth, error handling, pagination, registry, tests, docs)
Weakness: No concrete code examples or templates — guidance is procedural but lacks reference implementations
Weakness: No error handling guidance — what if the repo has inconsistent patterns or outdated connectors?
Weakness: Limited scope definition — does not specify which languages, frameworks, or API paradigms are in scope
Weakness: 'Related Skills' are listed but not explained — unclear how to know when to defer to backend-patterns or mcp-server-patterns instead

Model: claude-haiku-4-5-20251001Analyzed: Jul 14, 2026

Reviews

Add this skill to your library to leave a review.

No reviews yet

Be the first to share your experience.

Version History

v1.2

Content updated

2026-07-14

Latest

v1.1