kashflow
Kashflow 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 Kashflow. Routes through Apideck with serviceId "kashflow".
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, when to use it, and includes strong trigger terms for the accounting domain. Its main weakness is potential overlap with other Apideck accounting connector skills, since the capabilities described are identical across connectors with only the service name differentiating them. The explicit 'Use when' clause and specific entity types (invoices, bills, payments, etc.) make it highly functional for skill selection.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'read, write, or reconcile invoices, bills, payments, ledger accounts, and journal entries.' Also mentions the integration mechanism (Apideck unified API, serviceId). | 3 / 3 |
Completeness | Clearly answers both 'what' (Kashflow 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 Kashflow'). Explicit 'Use when' clause is present. | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'Kashflow', 'invoices', 'bills', 'payments', 'ledger accounts', 'journal entries', 'reconcile', 'Apideck', 'Accounting'. Good coverage of accounting domain terms and the specific service name. | 3 / 3 |
Distinctiveness Conflict Risk | While 'Kashflow' and 'serviceId kashflow' are distinctive, the description mentions it uses the same unified API methods as every other Apideck Accounting connector. If there are multiple Apideck accounting skills (e.g., for QuickBooks, Xero), the overlap in capabilities (invoices, bills, payments, etc.) could cause confusion — only the serviceId and 'Kashflow' name distinguish 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 well-structured connector skill with strong actionability through executable examples and excellent progressive disclosure via clear references to SDK skills and specs. Main weaknesses are moderate verbosity (repeated portability messaging, marketing language) and missing validation/error-handling guidance for a beta connector where partial coverage makes verification especially important.
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.
Add a brief validation step showing how to check the response status and handle cases where a beta endpoint returns unsupported-operation errors, e.g., checking for 4xx status codes or using the connector-coverage skill before making calls.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill contains some unnecessary verbosity — the 'Portable across 34 Accounting connectors' section repeats the portability concept already stated in the intro, and the 'When to use this skill' section over-explains activation triggers. 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, switching connectors, and using the Proxy API escape hatch with a complete curl command. The entity mapping table and coverage highlights give concrete, specific guidance on what works and what doesn't. | 3 / 3 |
Workflow Clarity | The skill covers a relatively simple task (API calls) but lacks explicit validation steps — there's no guidance on checking responses, handling errors, or verifying that a beta connector actually supports the requested operation before proceeding. The coverage check is mentioned ('see below') but not shown inline as a workflow step. | 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. Content is appropriately split between this connector-specific skill and the referenced SDK/architecture 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 | |
- 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.