API Connector Builder
SkillAI & modelsThis skill lets your AI add a new API connector or provider to a project by following the way integrations are already built in that repository. The result is one more working connection that fits your current setup instead of a second, different design.
Available today. Use it from your connected AI after setup.
No other account needed.
After adding it, point your AI at the repository that holds your existing integrations and name the API you want to connect. It will study the current pattern and build the new connector to match.
Then ask your AI: use the API Connector Builder skill
What your AI can do with it
- Build a new API connector for a service you want to reach
- Match the integration pattern already used in your repository
- Add one more provider without inventing a second design
- Keep new integrations consistent with the ones you already have
- Extend your project by following existing integration examples
What this skill tells your AI
The instructions your AI receives, as published by dekaprayoga/aurixagent in skills/api-connector-builder/SKILL.md and read by ahel’s review.
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
Signals
- GitHub stars
- 63
- Forks
- 11
- Last commit
- Aug 2026
ahel recommends instead
Advanced
- Catalog kind
- skill
- Gateway key
api-connector-builder-dekaprayoga- Source
- github.com/dekaprayoga/aurixagent