---

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