Access Financials 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 Access Financials. Routes through Apideck with serviceId "access-financials".
87
86%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Advisory
Suggest reviewing before use
Quality
Discovery
100%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 skill description that clearly identifies the specific integration (Access Financials via Apideck), lists concrete accounting operations (invoices, bills, payments, ledger accounts, journal entries), and provides an explicit 'Use when' clause with natural trigger terms. The mention of serviceId and the Apideck unified API pattern adds technical precision that aids disambiguation from similar accounting skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'read, write, or reconcile invoices, bills, payments, ledger accounts, and journal entries.' Also specifies the integration mechanism (Apideck's Accounting unified API, serviceId). | 3 / 3 |
Completeness | Clearly answers both 'what' (Access Financials integration via Apideck for accounting operations) and 'when' ('Use when the user wants to read, write, or reconcile invoices, bills, payments, ledger accounts, and journal entries in Access Financials'). | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'invoices', 'bills', 'payments', 'ledger accounts', 'journal entries', 'Access Financials', 'reconcile', plus technical identifiers like 'serviceId' and 'Apideck'. Good coverage of accounting domain terms. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with the specific product name 'Access Financials', the serviceId 'access-financials', and the Apideck routing mechanism. Clearly distinguishable from other accounting connector skills by the explicit service identifier. | 3 / 3 |
Total | 12 / 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 solid connector skill with good actionability through executable code examples and excellent progressive disclosure via well-organized references. Its main weaknesses are moderate verbosity (marketing language, repeated portability messaging) and a lack of explicit verification/fallback workflows for a beta connector where partial coverage is a known issue.
Suggestions
Remove the 'Portable across 34 Accounting connectors' section or reduce it to a single sentence — the portability concept is already stated in the intro paragraph.
Add an explicit workflow for handling beta coverage gaps: 1) Check coverage programmatically, 2) Attempt unified API call, 3) If unsupported, fall back to Proxy API — with a concrete code example showing error detection.
Trim the 'When to use this skill' section to 1-2 lines — Claude doesn't need a numbered list explaining what the skill teaches.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill contains some unnecessary padding — the 'Portable across 34 Accounting connectors' section repeats the portability concept already stated in the intro, the 'When to use this skill' section over-explains when activation is appropriate, and the marketing-style language about 'compounding advantage' adds no actionable value. However, the entity mapping table and coverage highlights are efficient. | 2 / 3 |
Actionability | Provides fully executable TypeScript examples for listing invoices and customers, a complete curl command for the Proxy API escape hatch, and a clear entity mapping table. The code is copy-paste ready with proper environment variable references and correct serviceId usage. | 3 / 3 |
Workflow Clarity | The skill covers a relatively simple task (API calls with a serviceId), but for a beta connector with partial coverage, there's no explicit workflow for verifying coverage before making calls or handling failures. The 'verify with connector API' note is vague, and there's no feedback loop for when operations fail due to coverage gaps. | 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, OpenAPI specs, best practices, connector coverage tools, and official docs. The 'See also' section and inline links to sibling skills are well-organized. | 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.