api-connector-builder — Claude Code skill: install
This skill builds an API connector by following the target repository’s existing integration pattern. Use it when a new provider should fit the current architecture.
npx skills add affaan-m/ECC --skill api-connector-builder -a claude-codeWhat api-connector-builder does
api-connector-builder is for adding a connector or provider that looks native to the host repository. It starts by reviewing at least 2 existing integrations, then maps their file layout, configuration model, authentication, error handling, registration hooks, and test style.
The work is split into repository-shaped layers: config and schema, client or transport, data mapping, connector entrypoint, registration, and tests. It also follows local conventions for retries, pagination, fixtures, and naming. Documentation and examples are updated when the repository expects them.
Install this skill when the codebase already has a clear integration pattern to follow. A repository without that pattern still needs a separate architecture decision.
What it helps with
- add a Jira connector that matches the project
- create a Slack provider with repository registration
- build a new integration for an API
- follow existing retry and pagination conventions
- cover a connector with repo-style tests
Example prompts for the agent
- “Build a Jira connector for this project”
- “Add a Slack provider following the existing pattern”
- “Create a new integration for this API”
How to install api-connector-builder
1Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill api-connector-builder -a claude-code2Manually: put the files in place
~/.claude/skills/api-connector-builder/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/api-connector-builder/
1Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill api-connector-builder -a codex2Manually: put the files in place
.agents/skills/api-connector-builder/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill api-connector-builder -a cursor2Manually: put the files in place
.cursor/skills/api-connector-builder/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install affaan-m/ECC api-connector-builder2Manually: put the files in place
.github/skills/api-connector-builder/SKILL.md1Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill api-connector-builder -a gemini-cli2Platform CLI
gemini skills install https://github.com/affaan-m/ECC --path skills/api-connector-builderManually: put the files in place
.devin/skills/api-connector-builder/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill api-connector-builder -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
From the same set146
The whole set →Similar
Questions about api-connector-builder
How do I install api-connector-builder in Claude Code?
Run npx skills add affaan-m/ECC --skill api-connector-builder -a claude-code. The skill file is placed at ~/.claude/skills/api-connector-builder/SKILL.md.
What does api-connector-builder do?
It helps build an API connector or provider around the repository’s current integration pattern. The workflow covers configuration, authentication, error handling, registration, and tests.
Which platforms support api-connector-builder?
The skill supports Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, and OpenCode.
Source text
SKILL.md · MIT
---
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:
version: "1.0.0"
origin: ECC direct-port adaptation
---
# 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`
© affaan-m · MIT · affaan-m/ECC