campfire
Campfire integration via Apideck's Accounting unified API — same methods work across every connector in Accounting, switch by changing `serviceId`. Use when the user wants to read, write, or reconcile invoices, bills, payments, ledger accounts, and journal entries in Campfire. Routes through Apideck with serviceId "campfire".
84
82%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Advisory
Suggest reviewing before use
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 well-crafted description that clearly states what the skill does and when to use it, with good trigger terms covering common accounting concepts. Its main weakness is potential conflict with other Apideck accounting connector skills, since the description explicitly notes the methods are shared across connectors and only the serviceId differentiates them.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: read, write, reconcile invoices, bills, payments, ledger accounts, and journal entries. Also mentions the technical mechanism (Apideck unified API, serviceId). | 3 / 3 |
Completeness | Clearly answers both what (read, write, reconcile invoices, bills, payments, ledger accounts, journal entries in Campfire via Apideck) and when ('Use when the user wants to read, write, or reconcile invoices, bills, payments...'). | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'invoices', 'bills', 'payments', 'ledger accounts', 'journal entries', 'Campfire', 'reconcile', 'accounting'. Good coverage of domain-specific terms. | 3 / 3 |
Distinctiveness Conflict Risk | The description is specific to Campfire with serviceId 'campfire', but the mention that 'same methods work across every connector in Accounting' and the generic accounting operations (invoices, bills, payments) could easily overlap with other Apideck accounting connector skills for different services. Only the service name distinguishes it. | 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.
A solid connector skill with good actionability through executable examples and excellent progressive disclosure via well-organized references. Main weaknesses are moderate verbosity from repeated portability messaging and marketing language, plus a lack of validation/error-handling guidance that would be especially valuable given the beta status of this connector.
Suggestions
Remove or condense the 'Portable across 34 Accounting connectors' section — the portability point is already made in the intro and the code example could be folded into the minimal example section.
Add a brief validation step or error-handling note, e.g., checking response status codes and handling cases where a beta resource returns 404/501, especially given the documented coverage gaps.
Trim the 'When to use this skill' section to 1-2 lines — Claude doesn't need detailed activation trigger explanations.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill contains some unnecessary verbosity — the 'Portable across 34 Accounting connectors' section repeats the portability pitch already made in the intro, and the 'When to use this skill' section over-explains activation triggers Claude can infer. The entity mapping table and coverage highlights are valuable, but the marketing-style language ('compounding advantage') wastes tokens. | 2 / 3 |
Actionability | Provides fully executable TypeScript examples for listing invoices, listing bills with filters, and using the Proxy API escape hatch with a complete curl command. The entity mapping table and coverage highlights give concrete guidance on what's supported vs. what requires the Proxy. | 3 / 3 |
Workflow Clarity | The skill covers a relatively simple task (API calls to Campfire via Apideck), so deep multi-step workflows aren't strictly needed. However, there's no validation or error-handling guidance — no mention of checking response status, handling pagination, or verifying that a beta connector actually supports the requested operation before proceeding. For a beta connector with known gaps, a verify-then-act workflow would be important. | 2 / 3 |
Progressive Disclosure | Excellent progressive disclosure: the skill provides a concise overview with clear one-level-deep references to SDK skills, OpenAPI specs, best practices, connector coverage tools, and official docs. Navigation is well-signaled with links and a dedicated 'See also' section. | 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.