JobAdder integration via Apideck's ATS unified API — same methods work across every connector in ATS, switch by changing `serviceId`. Use when the user wants to read, write, or sync jobs, applicants, and applications in JobAdder. Routes through Apideck with serviceId "jobadder".
83
81%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Quality
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 well-crafted description that clearly identifies its niche (JobAdder via Apideck ATS API), provides explicit 'Use when' guidance, and includes distinctive trigger terms like 'JobAdder' and 'serviceId'. The main weakness is that the specific actions could be more granular — listing concrete operations like 'create applicants', 'list jobs', or 'update applications' rather than the broader 'read, write, or sync'.
Suggestions
Expand the action list with more specific operations (e.g., 'create and update applicants, list and post jobs, manage application stages') to improve specificity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (JobAdder integration via Apideck ATS API) and mentions some actions ('read, write, or sync jobs, applicants, and applications'), but doesn't list multiple specific concrete actions like creating applicants, updating job postings, or fetching application statuses. | 2 / 3 |
Completeness | Clearly answers both 'what' (JobAdder integration via Apideck's ATS unified API for reading, writing, syncing jobs/applicants/applications) and 'when' ('Use when the user wants to read, write, or sync jobs, applicants, and applications in JobAdder') with explicit trigger guidance. | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms: 'JobAdder', 'ATS', 'Apideck', 'jobs', 'applicants', 'applications', 'sync', 'read', 'write', and 'serviceId "jobadder"'. These cover terms a user would naturally use when working with this integration. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — specifically targets JobAdder via Apideck with serviceId 'jobadder', making it clearly distinguishable from other ATS integrations or general API skills. The mention of switching by 'serviceId' also clarifies its relationship to sibling skills. | 3 / 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.
The skill provides good actionable examples and excellent progressive disclosure with clear references to related skills. However, it suffers from verbosity — marketing-style explanations about portability and OAuth concepts that Claude already understands consume unnecessary tokens. The workflow for handling unsupported operations could be more explicitly sequenced with validation checkpoints.
Suggestions
Remove or drastically condense the 'Portable across 11 ATS connectors' section — the portability point is already made in the intro and the duplicate code examples waste tokens on a concept Claude can infer.
Condense the Authentication section to just the key facts (oauth2, managed by Vault, auto-refresh) and drop the explanation of OAuth flows and connection state progression.
Add an explicit numbered workflow: 1. Verify coverage → 2. Call unified API → 3. Handle UnsupportedOperationError → 4. Fall back to Proxy API, with a clear feedback loop for error cases.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill contains several sections that are unnecessarily verbose for Claude — the 'Portable across 11 ATS connectors' section is marketing copy rather than instruction, the 'When to use this skill' section over-explains activation triggers, and the authentication section explains OAuth concepts Claude already knows. The core information (serviceId, API surface, example code) could be delivered in roughly half the tokens. | 2 / 3 |
Actionability | The skill provides fully executable TypeScript code for listing applicants, 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 spread across multiple sections rather than presented as a clear sequence. The coverage verification step is mentioned but there's no explicit validation checkpoint or error-handling feedback loop for when operations fail or return UnsupportedOperationError. | 2 / 3 |
Progressive Disclosure | The skill is well-structured as an overview with clear one-level-deep references to SDK skills, best practices, connector coverage patterns, and the OpenAPI spec. Navigation is easy with well-signaled links to sibling connectors and related skills. | 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.