odoo
Odoo integration via Apideck's CRM, Accounting unified API — same methods work across every connector in CRM, Accounting, switch by changing `serviceId`. Use when the user wants to read, write, or search contacts, companies, leads, opportunities, activities, and pipelines in Odoo. Routes through Apideck with serviceId "odoo".
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 platform (Odoo), the integration mechanism (Apideck unified API), concrete actions (read, write, search), and specific entities (contacts, companies, leads, etc.). It includes an explicit 'Use when...' clause with natural trigger terms and is highly distinctive due to the Odoo + Apideck + serviceId specificity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions and entities: 'read, write, or search contacts, companies, leads, opportunities, activities, and pipelines in Odoo.' Also mentions the technical mechanism (Apideck unified API, serviceId). | 3 / 3 |
Completeness | Clearly answers both 'what' (Odoo integration via Apideck for CRM/Accounting operations) and 'when' ('Use when the user wants to read, write, or search contacts, companies, leads, opportunities, activities, and pipelines in Odoo'). Explicit 'Use when...' clause is present. | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'Odoo', 'contacts', 'companies', 'leads', 'opportunities', 'activities', 'pipelines', 'CRM', 'Accounting', 'Apideck'. These cover the domain well and match what users would naturally mention. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — specifically targets Odoo via Apideck with serviceId 'odoo'. The combination of the specific platform (Odoo), the integration layer (Apideck), and the serviceId makes it very unlikely to conflict with other CRM or accounting skills for different platforms. | 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-specific skill with good actionability through executable examples and excellent progressive disclosure via well-organized references. Its main weaknesses are moderate verbosity from repeated marketing-style portability messaging and the lack of an explicit workflow for handling the beta connector's coverage gaps, which is particularly important given the documented caveats about partial resource coverage.
Suggestions
Remove or consolidate the 'Portable across 21 CRM connectors' section — the portability point is already made in the intro and the code example could be folded into the minimal example section.
Add an explicit workflow for handling beta coverage gaps: check coverage → attempt unified call → inspect error → fall back to Proxy API, with a concrete error-handling code example.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill contains some unnecessary verbosity — the 'Portable across 21 CRM connectors' section repeats the portability pitch already made in the intro, and the marketing-style language ('compounding advantage') adds no actionable value. The entity mapping table and coverage highlights are useful but the surrounding prose could be tighter. | 2 / 3 |
Actionability | Provides fully executable TypeScript examples for listing contacts, listing invoices with filters, and a curl command for Proxy API access. The serviceId, auth type, and entity mappings are concrete and specific. Code is copy-paste ready with clear environment variable references. | 3 / 3 |
Workflow Clarity | The skill doesn't define a clear multi-step workflow with validation checkpoints. While it mentions falling back to Proxy API for unsupported operations and checking coverage, there's no explicit sequence like 'check coverage → attempt unified call → handle error → fall back to proxy.' For a connector in beta status where coverage gaps are expected, a validation/fallback 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, API Explorer, best practices, coverage checking tools, and Odoo docs. Content is well-organized into logical sections with clear navigation signals. | 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.