Apply production-ready Apollo.io SDK patterns. Use when implementing Apollo integrations, refactoring API usage, or establishing team coding standards. Trigger with phrases like "apollo sdk patterns", "apollo best practices", "apollo code patterns", "idiomatic apollo", "apollo client wrapper".
80
77%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/saas-packs/apollo-pack/skills/apollo-sdk-patterns/SKILL.mdQuality
Discovery
89%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 solid description with strong trigger terms and clear 'what/when' guidance. Its main weakness is that the 'what' portion is somewhat abstract — it says 'production-ready patterns' without specifying what those patterns concretely involve (e.g., error handling, pagination, rate limiting, authentication). Adding concrete actions would elevate the specificity.
Suggestions
Add specific concrete actions the skill covers, e.g., 'Implements error handling, pagination, rate limiting, and authentication for Apollo.io API calls' to improve specificity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (Apollo.io SDK) and mentions some actions like 'implementing Apollo integrations, refactoring API usage, establishing team coding standards', but these are fairly general and don't list specific concrete actions like 'wrap API endpoints, handle pagination, implement retry logic'. | 2 / 3 |
Completeness | Clearly answers both 'what' (apply production-ready Apollo.io SDK patterns) and 'when' (implementing Apollo integrations, refactoring API usage, establishing team coding standards), with explicit trigger phrases provided. | 3 / 3 |
Trigger Term Quality | Includes a good set of natural trigger terms: 'apollo sdk patterns', 'apollo best practices', 'apollo code patterns', 'idiomatic apollo', 'apollo client wrapper'. These cover multiple natural phrasings a user might use, and the explicit 'Trigger with phrases like...' clause is helpful. | 3 / 3 |
Distinctiveness Conflict Risk | Apollo.io SDK is a very specific niche. The description clearly targets Apollo.io integrations with distinct trigger terms that are unlikely to conflict with other skills, unless there's a separate Apollo GraphQL skill — but the '.io' qualifier and terms like 'client wrapper' help distinguish it. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a highly actionable skill with production-ready, executable TypeScript code covering all key Apollo API integration patterns. Its main weaknesses are its length (all five files fully inline rather than progressively disclosed) and the lack of explicit validation/verification steps between workflow stages. The error handling table and some usage comments add minor redundancy.
Suggestions
Add explicit validation checkpoints between steps, e.g., 'Test the client with a simple GET to /auth/health before proceeding' or 'Verify pagination returns expected page count before running bulk enrichment'.
Move the full implementations of errors.ts, retry.ts, paginator.ts, and bulk-enrich.ts into a referenced file (e.g., APOLLO-PATTERNS-REFERENCE.md) and keep only client.ts and the full pipeline example inline for a leaner SKILL.md.
Remove the Error Handling table — it restates what's already clear from the code and step descriptions.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient with executable code, but is quite long (~200 lines of code). Some sections like the Error Handling table restate what's already obvious from the code. The 'Examples' section partially duplicates the pagination usage comment already shown in Step 4. However, it avoids explaining basic concepts Claude already knows. | 2 / 3 |
Actionability | Every step provides fully executable, copy-paste-ready TypeScript code with proper imports, file paths, and complete implementations. The code is production-quality with Zod validation, proper error classes, retry logic, and pagination — all immediately usable. | 3 / 3 |
Workflow Clarity | Steps are clearly numbered and sequenced (client → errors → retry → pagination → bulk enrichment), and the full pipeline example ties them together. However, there are no explicit validation checkpoints — no instructions to verify the client works, test error handling, or validate that pagination returns expected results before proceeding to bulk operations. | 2 / 3 |
Progressive Disclosure | The skill has good section structure and references external resources and a next-step skill. However, the content is monolithic — all five implementation files are fully inline rather than being split into referenced files. The Output section lists the files but the full code could be in separate referenced documents with just the client.ts shown inline as a quick start. | 2 / 3 |
Total | 9 / 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 |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
3e83543
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.