Agent Skills
› NeverSight/learn-skills.dev
› api-connector-builder
api-connector-builder
GitHub用于构建与目标仓库现有集成模式完全一致的新API连接器或提供者。避免发明新架构，强调遵循仓库的文件布局、配置、认证及测试规范，确保新组件无缝融入现有代码库。
Trigger Scenarios
构建新的API连接器
添加遵循现有模式的集成
创建匹配仓库风格的插件
Install
npx skills add NeverSight/learn-skills.dev --skill api-connector-builder -g -y
SKILL.md
Frontmatter
{
"name": "api-connector-builder",
"origin": "ECC direct-port adaptation",
"version": "1.0.0",
"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."
}
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
providers/
existing_provider/
__init__.py
provider.py
config.py
Connector-style
integrations/
existing/
client.py
models.py
connector.py
TypeScript plugin-style
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-patternsmcp-server-patternsgithub-ops
Version History
- e0220ca Current 2026-07-05 23:51
