api-connector-builder

name	api-connector-builder
description	通过完全匹配目标存储库的现有集成模式来构建新的 API 连接器或提供商。当在不发明第二种架构的情况下添加另一个集成时使用。
origin	ECC direct-port adaptation
version	1.0.0

API 连接器构建器

当任务是添加存储库原生集成表面而不仅仅是通用 HTTP 客户端时使用此技能。

重点是匹配主机存储库的模式：

• 连接器布局
• 配置架构
• 身份验证模型
• 错误处理
• 测试样式
• 注册/发现接线

何时使用

• "为此项目构建 Jira 连接器"
• "遵循现有模式添加 Slack 提供商"
• "为此 API 创建新集成"
• "构建匹配存储库连接器样式的插件"

保护措施

• 当存储库已有一个集成架构时，不要发明新的集成架构
• 不要仅从供应商文档开始；首先从存储库中现有的连接器开始
• 如果存储库期望注册接线、测试和文档，不要在传输代码处停止
• 如果存储库有更新的当前模式，不要盲目模仿旧连接器

工作流程

1. 了解内部样式

检查至少 2 个现有的连接器/提供商并映射：

• 文件布局
• 抽象边界
• 配置模型
• 重试/分页约定
• 注册挂钩
• 测试夹具和命名

2. 缩小目标集成范围

仅定义存储库实际需要的表面：

• 身份验证流程
• 关键实体
• 核心读/写操作
• 分页和速率限制
• webhook 或轮询模型

3. 按存储库原生层构建

典型切片：

• 配置/架构
• 客户端/传输
• 映射层
• 连接器/提供商入口点
• 注册
• 测试

4. 根据源模式验证

新连接器在代码库中应该看起来明显，而非从不同生态系统导入。

参考形状

提供商风格

providers/
  existing_provider/
    __init__.py
    provider.py
    config.py

连接器风格

integrations/
  existing/
    client.py
    models.py
    connector.py

TypeScript 插件风格

src/integrations/
  existing/
    index.ts
    client.ts
    types.ts
    test.ts

质量检查清单

• 匹配现有的存储库内集成模式
• 配置验证存在
• 身份验证和错误处理是明确的
• 分页/重试行为遵循存储库规范
• 注册/发现接线完成
• 测试镜像主机存储库的样式
• 文档/示例已更新（如果存储库期望）

相关技能

• backend-patterns
• mcp-server-patterns
• github-ops