tdg-personal/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.
75
75%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
67%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description is competent with a clear 'Use when' clause that distinguishes its purpose (adding integrations that follow existing patterns rather than creating new architectures). However, it lacks specific concrete actions beyond 'build' and could benefit from more natural trigger terms that users would actually say. The domain is moderately well-scoped but could overlap with general API or integration skills.
Suggestions
Add more concrete actions such as 'scaffold connector files, implement authentication, map API endpoints, write integration tests' to improve specificity.
Include additional natural trigger terms like 'add a new integration', 'third-party API', 'service client', 'adapter', or 'plugin' to improve discoverability.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (API connectors/providers) and a key action (matching existing integration patterns), but doesn't list multiple concrete actions like scaffolding files, implementing auth methods, writing tests, etc. | 2 / 3 |
Completeness | Clearly answers both 'what' (build a new API connector/provider by matching existing patterns) and 'when' (use when adding one more integration without inventing a second architecture), with an explicit 'Use when' clause. | 3 / 3 |
Trigger Term Quality | Includes relevant terms like 'API connector', 'provider', 'integration pattern', but misses common user variations such as 'add a new integration', 'third-party API', 'SDK', 'plugin', 'adapter', or 'service client'. | 2 / 3 |
Distinctiveness Conflict Risk | The focus on matching existing repo patterns for API connectors is somewhat distinctive, but 'API connector' and 'integration' are broad enough to potentially overlap with general API development or refactoring skills. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
72%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured, concise skill that clearly communicates the meta-pattern of building repo-native API connectors. Its main weakness is the lack of executable examples or concrete validation steps — the guidance stays at the architectural/checklist level rather than providing specific code or commands. The quality checklist at the end partially compensates but doesn't replace explicit verification steps in the workflow.
Suggestions
Add a concrete validation step in the workflow, e.g., 'diff the file tree of your new connector against an existing one to verify structural parity' or a specific command/script to run.
Include at least one small executable code snippet showing a minimal connector skeleton (even if language-agnostic pseudocode is justified, a real Python or TypeScript example would be more actionable).
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is lean and efficient. It doesn't explain what APIs or connectors are, assumes Claude understands software architecture, and every section earns its place. The bullet-point style avoids unnecessary prose. | 3 / 3 |
Actionability | The guidance is concrete in terms of what to look for and what to produce, but lacks executable code examples. The workflow steps are directional rather than copy-paste ready — e.g., 'Inspect at least 2 existing connectors' is clear but there are no specific commands or code snippets showing how to implement any layer. | 2 / 3 |
Workflow Clarity | The 4-step workflow is well-sequenced and logical, but lacks explicit validation checkpoints or feedback loops. Step 4 ('Validate against the source pattern') is vague — it doesn't specify how to validate, what constitutes passing, or what to do if validation fails. For a skill involving multi-file code generation, a verify-fix-retry loop would be valuable. | 2 / 3 |
Progressive Disclosure | The content is well-structured with clear sections (When to Use, Guardrails, Workflow, Reference Shapes, Quality Checklist) and references related skills at the end. For a skill of this size (~80 lines), the organization is appropriate without needing external files, and navigation is easy. | 3 / 3 |
Total | 10 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
Reviewed
Table of Contents