Skip to content
Back to skills

Api Connector Builder

ASecurity

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.

  • 2 stars
  • 0 votes
  • 0 copies
  • 3 views
  • Added September 19, 2026
ai-agentsgorailsgitapi

Works with

  • cli
  • api

Security analysis

A100/100

Scanned September 19, 2026

npx -y skills add majinmagros/magros.ai-skills --skill api-connector-builder --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Api Connector Builder?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Api Connector Builder
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/majinmagros-api-connector-builder/badge)](https://www.skillsdirectory.com/skills/majinmagros-api-connector-builder)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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

## Exemplo

```text
Tarefa: "Build a Jira connector for this project"
1) Lê 2 conectores existentes (ex.: Slack, GitHub) → mapeia layout, auth, retry, fixtures
2) Define superfície mínima: auth OAuth, entidades issue/project, CRUD + paginação
3) Entrega em camadas do repo + registry wiring + testes no estilo da casa
Anti-padrão evitado: nada de arquitetura nova quando o repo já tem uma
```

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…