api-connector-builder
affaan-m/ecc
Build API connectors matching your repo's existing integration pattern exactly.
What is api-connector-builder?
This skill guides you through adding a new API connector or provider to a codebase by reverse-engineering and replicating the patterns already established in existing integrations. Use it when you need to add one more integration without inventing a second architecture.
- Analyze 2+ existing connectors to map file layout, abstraction boundaries, and config models
- Define the minimal surface needed: auth, entities, core operations, pagination, and webhook/polling model
- Build config/schema, client/transport, mapping, entrypoint, and registration layers in repo-native style
- Validate the new connector against source patterns so it looks native, not imported
- Ensure tests, error handling, and registry wiring match the host repo's conventions
How to install api-connector-builder
npx skills add null --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, and rate-limit behavior
- 3.Build the connector in layers: config/schema, client/transport, mapping, entrypoint, and registration—matching the repo's structure exactly
- 4.Write tests that mirror the host repo's test fixtures and naming conventions
- 5.Update docs and examples if the repo expects them, and verify the new connector looks native in the codebase
Use cases
- Add a Jira connector to a project that already has Slack and GitHub integrations
- Create a new provider following an existing provider pattern without inventing a second architecture
- Build a plugin-style integration for TypeScript that mirrors the repo's current integration layout
- Extend a Python connector framework with a new API client that matches existing config and auth models
- Add webhook or polling support to a new integration following the repo's established patterns
- Backend engineers extending integration frameworks
- Full-stack developers adding connectors to multi-provider platforms
- Maintainers onboarding new API integrations into established codebases
- Teams standardizing connector patterns across a repository
api-connector-builder FAQ
Always start from existing in-repo connectors first. They define the house style, abstraction boundaries, and registration wiring you must match. Vendor docs come second, to fill in API-specific details.
Use the newest or most-maintained pattern as your template. Avoid cargo-culting old connectors if the repo has evolved to a current standard.
Yes, but follow the repo's existing conventions. Don't invent your own; copy the pagination and retry model from an existing connector.
Whatever mechanism the repo uses to discover and register connectors: plugin loaders, factory functions, config-driven registration, or explicit imports. Match that exactly.
Yes, but wrap it in the repo's native layers (config, mapping, entrypoint) so the connector integrates seamlessly with the existing pattern.
Full instructions (SKILL.md)
Source of truth, from affaan-m/ecc.
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/ecc and the wider catalog.
api-design
REST API design patterns for resource naming, status codes, pagination, filtering, versioning, and rate limiting.
architecture-decision-records
Capture architectural decisions as structured ADRs during coding sessions so future developers understand the reasoning behind your codebase.
article-writing
Write long-form content in a distinctive voice, from blog posts to guides, without sounding like an LLM.
automation-audit-ops
Evidence-first inventory and overlap audit for automation jobs, hooks, connectors, and MCP servers.
autonomous-loops
Patterns and architectures for autonomous Claude Code loops, from sequential pipelines to RFC-driven multi-agent DAG systems.
backend-patterns
Backend architecture patterns, API design, database optimization, and best practices for Node.js, Express, and Next.js.