api-connector-builder
Добавление интеграции с внешним API в проект
Что получите
Новая интеграция, встроенная в существующую систему проекта и оформленная по её правилам.
Что передать
Репозиторий, целевой сервис и нужные операции интеграции.
Проверен состав файлов. Запуск не тестировался. Что проверено
Оценки пользователей
Как использовать
Помогает разработчикам добавить коннектор или поставщика данных по существующим правилам репозитория. Подходит для подключения нового сервиса с привычными для проекта настройками, авторизацией и обработкой ошибок.
- Начните с изучения минимум двух существующих интеграций и определите актуальный образец.
- Ограничьте задачу нужными сущностями и действиями, уточнив авторизацию и способ получения обновлений.
- Реализуйте интеграцию вместе с подключением к проекту, проверками и документацией, если этого требует репозиторий.
Условия работы
- Инструкция предназначена для интеграции внутри репозитория, а не только для универсального HTTP-клиента.
- Существующую архитектуру нужно сохранить; начинать только с документации внешнего сервиса или копировать устаревший образец нельзя.
- Нельзя ограничиться отправкой запросов, если проект также требует регистрации интеграции, проверок и документации.
Пример запроса после установки
Добавь коннектор Jira в наш проект по актуальному образцу существующих интеграций; нужны чтение задач, постраничная загрузка и создание комментариев.
Пример составлен по инструкции автора; результат запуска не проверялся.
Основание: инструкция закреплённой версииДля установки
Node.js, npm и Git для команды выше. Подключения и инструменты для работы скилла настраиваются отдельно.
Совместимые агенты
Совместимость указана для инструкций. Запуск в каждом приложении не тестировался; для веб-чата способ подключения может отличаться.
Файлы скилла
GitHubЧитать инструкцию 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:
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`
Проверка и особенности
Автоматическая проверка источника и файлов
Автоматически проверены публичный репозиторий, лицензия, заголовок SKILL.md, состав текстового пакета и Git-хеш каждого файла. Пакеты с исполняемым кодом и срабатываниями применённых статических правил не включены. Ручной аудит всех инструкций и функциональный запуск не проводились. Внешние инструменты и сервисы не проверялись. Проверка не гарантирует безопасность.
У репозитория было 268,302 звёзд GitHub при проверке 2026-09-27. Порог добавления — строго больше 100 000. Звёзды относятся ко всему репозиторию, а не к качеству или установкам скилла.
- Проверка состава
- 27.09.2026
- Проверенная версия
e482e579415f- Файлы с кодом
- Не указаны в данных проверки
- Изменения на GitHub
- Нужна повторная проверкаПоследняя проверка: 11.10.2026
Репозиторий и лицензия
Это показатели всего репозитория, а не установки скилла. Снимок требует обновления.
- Последняя активность GitHub
- 11.10.2026
- Лицензия
- MIT
- Добавлен в каталог
- 27.09.2026
Полный текст лицензии
MIT License Copyright (c) 2026 Affaan Mustafa Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Ещё в этой категории
Все в категорииОбсуждение
ПравилаПользовались этим скиллом? Делитесь опытом без регистрации. Все комментарии проверяет модератор.
