Menu
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.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| 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 | {"origin":"HCP direct-port adaptation"} |
| version | 1.0.0 |
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:
Inspect at least 2 existing connectors/providers and map:
Define only the surface the repo actually needs:
Typical slices:
The new connector should look obvious in the codebase, not imported from a different ecosystem.
providers/
existing_provider/
__init__.py
provider.py
config.py
integrations/
existing/
client.py
models.py
connector.py
src/integrations/
existing/
index.ts
client.ts
types.ts
test.ts
backend-patternsmcp-server-patternsgithub-ops顽皮制造 — Fuse multiple external skill repos/sources into an existing skill to create a unified, more capable version. Use when the user says 'merge these skills', 'combine X into Y', 'absorb the best parts of A/B/C into Z', 'upgrade this skill with features from those repos', or provides multiple GitHub URLs and asks to integrate them into a single skill. Also triggers on 'audit these skills and see if they can enhance ours'.
Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.
Guides systematic root-cause debugging. Use when tests fail, builds break, behavior doesn't match expectations, or you encounter any unexpected error. Use when you need a systematic approach to finding and fixing the root cause rather than guessing.
Structures git workflow practices. Use when making any code change. Use when committing, branching, resolving conflicts, or when you need to organize work across multiple parallel streams.
Breaks work into ordered tasks. Use when you have a spec or clear requirements and need to break work into implementable tasks. Use when a task feels too large to start, when you need to estimate scope, or when parallel work is possible.
Drives development with tests. Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality.