Api Connector Builder
Add a Jira, Slack, or other API connector that mirrors how your repo already registers auth, config, errors, and tests.
Overview
API Connector Builder is an agent skill for the Build phase that adds a new API connector by copying the host repository’s existing integration layout, auth, tests, and registry wiring.
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill api-connector-builderWhat is this skill?
- Start from at least two in-repo connectors before reading vendor docs
- Guardrails: no second integration architecture, no stopping at transport without registry/tests/docs
- Maps house style—layout, config, retry/pagination, abstraction boundaries
- Narrows target surface to auth flow, key entities, and core ops the repo actually needs
- Direct-port ECC adaptation version 1.0.0 for repo-native provider work
- Workflow step 1: inspect at least 2 existing connectors/providers
Adoption & trust: 3.1k installs on skills.sh; 210k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need another SaaS integration but every new attempt invents a different folder structure, config shape, and test style than the rest of the repo.
Who is it for?
Repos that already have two or more integrations and a clear connector pattern you must extend for the next vendor.
Skip if: Greenfield projects with zero in-repo examples where you must design the first integration architecture from scratch.
When should I use this skill?
Build a Jira/Slack-style connector, add a provider following the existing pattern, or create a new API integration that matches the repo’s connector style.
What do I get? / Deliverables
You ship a provider that registers like existing connectors—with config, errors, pagination, and tests aligned—rather than an orphaned HTTP wrapper.
- New connector/provider files matching house layout
- Config schema and registry registration
- Tests and fixtures consistent with sibling integrations
Recommended Skills
Journey fit
New external integrations are core Build work—the skill exists to extend the product surface, not to validate ideas or run ops dashboards. Integrations subphase is exact: registry wiring, provider layout, and repo-native connector patterns—not generic HTTP snippets alone.
How it compares
Repo-native connector workflow—not a generic OpenAPI client generator that ignores registry and test conventions.
Common Questions / FAQ
Who is api-connector-builder for?
Solo builders extending an existing codebase with one more external API using the same connector/provider pattern the project already uses.
When should I use api-connector-builder?
During Build/integrations when you are asked to add Jira, Slack, or similar and must match layout, auth, retries, and registration hooks already in the tree.
Is api-connector-builder safe to install?
It guides code you write locally; review the Security Audits panel on this page and treat API keys and network calls per your project’s security rules.
SKILL.md
READMESKILL.md - Api Connector Builder
# 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 ```text providers/ existing_provider/ __init__.py provider.py config.py ``` ### Connector-style ```text integrations/ existing/ client.py models.py connector.py ``` ### TypeScript plugin-style ```text 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`