跳到主要内容
知仓学习社ZHICANG

api-connector-builder

通过匹配目标仓库现有的集成模式,构建一个新的API连接器或提供者。适用于在不发明第二种架构的情况下添加一个集成。

不碰外部(只输出文字)无严重或高危命中affaan-m/ECC

它会碰到什么

扫了多少1 个文本文件,1 KB
它会碰到什么不碰外部(只输出文字)
命中总数0 处
命中统计严重 0 · 高 0 · 中 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

想直接用这个技能?

本站把开放许可(MIT / Apache 等)的技能按仓库打包整理到网盘,点一下转存到你自己的网盘,不用一个个从 GitHub 拉。许可未声明的技能只给原始仓库链接,不打包。

同名技能的其他版本

有 3 个不同仓库或目录里都有叫 api-connector-builder 的技能。它们内容并不相同,别混用:

  • affaan-m/ECC — ターゲット リポジトリの既存統合パターンに正確に一致する新しい API コネクターまたはプロバイダーを構築します。2 番目のアーキテクチャを発明せずに、1 つ以上の統合を追加すると
  • affaan-m/ECC — Build a new API connector or provider by matching the target repo's existing integration p