Google Contacts integration via Apideck's CRM unified API — same methods work across every connector in CRM, switch by changing `serviceId`. Use when the user wants to read, write, or search contacts, companies, leads, opportunities, activities, and pipelines in Google Contacts. Routes through Apideck with serviceId "google-contacts".
84
82%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
92%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a strong description that clearly communicates what the skill does, when to use it, and includes rich trigger terms. The main weakness is potential overlap with other Apideck CRM connector skills since the description explicitly notes the same methods work across connectors, which could create ambiguity in multi-connector environments. The description uses appropriate third-person voice and is concise yet comprehensive.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'read, write, or search contacts, companies, leads, opportunities, activities, and pipelines.' Also specifies the integration mechanism (Apideck's CRM unified API) and the serviceId pattern. | 3 / 3 |
Completeness | Clearly answers both 'what' (Google Contacts integration via Apideck CRM unified API with read/write/search capabilities across multiple entity types) and 'when' (explicit 'Use when the user wants to read, write, or search contacts, companies, leads, opportunities, activities, and pipelines in Google Contacts'). | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'contacts', 'companies', 'leads', 'opportunities', 'activities', 'pipelines', 'Google Contacts', 'CRM', 'read', 'write', 'search'. Good coverage of domain-specific terms a user would naturally mention. | 3 / 3 |
Distinctiveness Conflict Risk | While it specifies 'Google Contacts' and the serviceId 'google-contacts', the description mentions it uses the same CRM unified API methods as other connectors. In a workspace with multiple Apideck CRM connector skills (e.g., Salesforce, HubSpot), the overlap in entity types (contacts, leads, opportunities) could cause confusion, though the serviceId and 'Google Contacts' mentions help differentiate. | 2 / 3 |
Total | 11 / 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 connector skill with strong actionability and excellent progressive disclosure to related skills and documentation. Its main weaknesses are verbosity from marketing-style explanations about Apideck's value proposition and a workflow that could be more explicitly sequenced with validation checkpoints for the coverage-check-then-call pattern.
Suggestions
Remove or drastically shorten the 'Portable across 21 CRM connectors' section — the portability point is already made in the intro and the sibling connectors section; the marketing language wastes tokens.
Restructure the implicit workflow (verify coverage → call unified API → handle UnsupportedOperationError → fall back to proxy) as an explicit numbered sequence with decision points.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill contains some unnecessary verbosity — the 'Portable across 21 CRM connectors' section is marketing-style explanation that Claude doesn't need, and phrases like 'This is the compounding advantage of using Apideck over integrating Google Contacts directly' are filler. The 'When to use this skill' section also over-explains. However, the core technical content is reasonably efficient. | 2 / 3 |
Actionability | Provides fully executable TypeScript code for listing contacts, concrete curl commands for coverage verification and proxy API usage, and specific serviceId strings. The examples are copy-paste ready with clear environment variable references. | 3 / 3 |
Workflow Clarity | There's an implicit workflow (check coverage → use unified API → fall back to proxy if unsupported), but it's not presented as a clear sequential process with validation checkpoints. The coverage verification step exists but isn't integrated into a coherent workflow with explicit decision points or error handling feedback loops. | 2 / 3 |
Progressive Disclosure | Excellent progressive disclosure with a clear overview in the main file and well-signaled one-level-deep references to SDK skills, best practices, connector coverage patterns, and external specs. The 'See also' section provides clean navigation to related resources. | 3 / 3 |
Total | 10 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
metadata_field | 'metadata' should map string keys to string values | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
9e04d86
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.