elias/everything-claude-code
1
0
Fork 0
mirror of https://github.com/affaan-m/everything-claude-code.git synced 2026-06-16 16:36:53 +08:00
Code Issues Packages Projects Releases Wiki Activity
everything-claude-code/skills/api-connector-builder/SKILL.md
BERORINPO db7f2a6fd5 fix(skills): move top-level origin frontmatter key under metadata 
The official Agent Skills spec (agentskills.io/specification) whitelists exactly
6 top-level frontmatter keys (name/description/license/compatibility/metadata/
allowed-tools). A top-level `origin` key fails the official validator
(anthropics/skills quick_validate.py ALLOWED_PROPERTIES; skills-ref validate).

This moves `origin: X` -> `metadata.origin: X` across the canonical skills/
tree, preserving each value verbatim. Frontmatter-only, minimal diff.

- 251 SKILL.md updated (242 new metadata block, 9 appended to existing metadata)
- origin values preserved verbatim (verified 251/251)
- YAML validated on all changed files
- scoped to canonical skills/ only (docs/<lang> translations + tool mirrors
  .cursor/.kiro/.agents left untouched; presumably regenerated from canonical)

Addresses #2233
2026-06-11 21:12:21 +09:00

2.6 KiB
Raw Blame History

name, description, metadata, version
name description metadata version
api-connector-builder 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.
origin
ECC direct-port adaptation
1.0.0

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-patterns
  • mcp-server-patterns
  • github-ops