bullhorn-ats
Bullhorn ATS 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 Bullhorn ATS. Routes through Apideck with serviceId "bullhorn-ats".
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 solid skill description that clearly identifies its niche (Bullhorn ATS via Apideck), includes an explicit 'Use when' clause with relevant trigger terms, and is highly distinctive. The main weakness is that the specific capabilities could be more granular — listing concrete operations like 'create candidates', 'list job postings', or 'update application status' rather than the broader 'read, write, or sync'.
Suggestions
Expand the capability list with more specific actions, e.g., 'create/update candidates, list job postings, manage application statuses, sync hiring pipeline data' instead of the generic 'read, write, or sync'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Bullhorn ATS integration via Apideck) and some actions ('read, write, or sync jobs, applicants, and applications'), but doesn't list multiple concrete specific actions like creating candidates, updating job postings, or pulling application statuses. | 2 / 3 |
Completeness | Clearly answers both 'what' (Bullhorn ATS integration via Apideck's 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 Bullhorn ATS') with explicit trigger guidance. | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'Bullhorn', 'ATS', 'Apideck', 'jobs', 'applicants', 'applications', 'sync', 'serviceId', and 'bullhorn-ats'. Good coverage of terms a user working with this integration would naturally use. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — specifically targets Bullhorn ATS via Apideck with the serviceId 'bullhorn-ats'. The mention of the specific connector and serviceId makes it very unlikely to conflict with other ATS or API 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.
This is a well-structured connector skill with strong actionability and progressive disclosure. Its main weaknesses are moderate verbosity (marketing-style explanations of Apideck's value proposition that Claude doesn't need) and a workflow that could be more explicitly sequenced with validation checkpoints for the coverage-check-then-call pattern.
Suggestions
Remove or significantly trim the 'Portable across 11 ATS connectors' section — Claude doesn't need to be sold on Apideck's value proposition; the portability is already clear from the quick facts and sibling connectors section.
Add an explicit numbered workflow: 1. Verify coverage → 2. Call unified API → 3. Handle UnsupportedOperationError → 4. Fall back to Proxy API, with concrete error checking code inline rather than delegating entirely to another skill.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill includes some unnecessary verbosity — the 'Portable across 11 ATS connectors' section is marketing-flavored and explains the value proposition of Apideck rather than providing actionable guidance. The 'When to use this skill' section also over-explains. However, the core content (examples, auth, proxy) is reasonably efficient. | 2 / 3 |
Actionability | Provides fully executable TypeScript code for listing applicants, a concrete curl command for verifying coverage, and a complete proxy API escape hatch with real headers. All examples are copy-paste ready with clear variable substitution. | 3 / 3 |
Workflow Clarity | The skill implies a workflow (check coverage → use unified API → fall back to proxy if unsupported) but doesn't explicitly sequence these steps with validation checkpoints. There's no explicit error handling flow for when operations fail or return UnsupportedOperationError — it just references another skill. | 2 / 3 |
Progressive Disclosure | Excellent progressive disclosure with a concise overview and well-signaled one-level-deep references to SDK skills, best practices, connector coverage, and the OpenAPI spec. The 'See also' section provides clear navigation without nesting references multiple levels deep. | 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 | |
- Repository
- apideck-libraries/api-skills
- Commit
9e04d86
- Reviewed
Table of Contents
Is this your skill?
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.