api-connector-builder
affaan-m/everything-claude-code
Build API connectors matching your repo's existing integration pattern exactly.
What is api-connector-builder?
This skill helps you add a new API connector or provider to a codebase by analyzing and replicating the repository's established integration architecture. Use it when you need to add another integration without inventing a new pattern or architecture.
- Analyze existing connectors to extract the repo's integration pattern (layout, config, auth, error handling)
- Map abstraction boundaries, registry hooks, and test conventions from 2+ existing integrations
- Build new connectors in matching layers: config, client/transport, mapping, entrypoint, registration, and tests
- Validate that new connectors follow repo norms for pagination, retry behavior, and webhook/polling models
- Generate registry wiring and test fixtures that mirror the host repo's style
How to install api-connector-builder
npx skills add https://github.com/affaan-m/everything-claude-code --skill api-connector-builderHow to use api-connector-builder
- 1.Inspect at least 2 existing connectors in the target repo and document their file layout, config schema, auth model, and test style
- 2.Define the scope of the new integration: auth flow, key entities, core operations, pagination/rate limits, and webhook vs. polling approach
- 3.Build the new connector in repo-native layers: config/schema, client/transport, mapping, entrypoint, registration, and tests
- 4.Cross-check the new connector against the source pattern to ensure it looks native to the codebase, not imported from elsewhere
- 5.Validate config validation, auth/error handling, pagination/retry behavior, registry wiring, and test coverage match repo norms
Use cases
- Add a Jira connector to a project that already has Slack and GitHub integrations
- Create a new Stripe provider following an existing payment provider's pattern
- Build a custom API integration for an internal tool matching the repo's connector architecture
- Add webhook support to a new integration using the repo's established polling/webhook model
- Extend an integration framework with a new data source without inventing a second architecture
- Backend engineers extending integration frameworks
- Platform teams adding vendor connectors to existing systems
- Developers maintaining multi-connector projects
- Contributors adding integrations to open-source projects
api-connector-builder FAQ
No. Start by studying existing in-repo connectors first. Use vendor docs only after you understand the repo's pattern.
Identify the newest or most current pattern and follow that. Do not cargo-cult older connectors if the repo has evolved.
Yes. Do not stop at transport code. Include test fixtures, registry hooks, and documentation updates if the repo expects them.
Your new connector should look obvious and native in the codebase, not like it was imported from a different ecosystem or framework.
This skill assumes an existing pattern exists. If the repo has no prior integrations, consider using backend-patterns or mcp-server-patterns instead.
Full instructions (SKILL.md)
Source of truth, from affaan-m/everything-claude-code.
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: origin: ECC direct-port adaptation version: "1.0.0"
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-patternsmcp-server-patternsgithub-ops
Related skills
More from affaan-m/everything-claude-code and the wider catalog.

security-review
Security checklist and patterns for authentication, input validation, secrets, and sensitive features.

golang-patterns
Idiomatic Go patterns, best practices, and conventions for building robust, efficient, and maintainable applications.

coding-standards
Baseline coding conventions for naming, readability, immutability, and quality across projects.

frontend-patterns
React and Next.js patterns for components, state management, performance, and modern frontend practices.

backend-patterns
REST/GraphQL API design, database optimization, and server-side patterns for Node.js, Express, and Next.js.

golang-testing
Go testing patterns: table-driven tests, subtests, benchmarks, fuzzing, and TDD methodology.