linear
Linear integration via Apideck's Issue Tracking unified API — same methods work across every connector in Issue Tracking, switch by changing `serviceId`. Use when the user wants to read, write, or comment on tickets and issues in Linear. Routes through Apideck with serviceId "linear".
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 description that clearly identifies the integration target (Linear via Apideck), provides explicit trigger guidance, and is distinctive enough to avoid conflicts. The main weakness is that the specific capabilities could be more granular — listing concrete actions like creating issues, updating statuses, or managing labels would strengthen the specificity dimension.
Suggestions
Expand the action list to include more specific operations like 'create issues, update statuses, assign users, list projects, and add comments' instead of the general 'read, write, or comment'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Linear issue tracking) and some actions ('read, write, or comment on tickets and issues'), but doesn't list comprehensive specific actions like creating issues, updating statuses, assigning users, listing projects, etc. | 2 / 3 |
Completeness | Clearly answers both 'what' (Linear integration via Apideck's Issue Tracking unified API for reading, writing, commenting on tickets) and 'when' ('Use when the user wants to read, write, or comment on tickets and issues in Linear'). | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms: 'Linear', 'tickets', 'issues', 'comment', 'read', 'write', 'Issue Tracking', 'Apideck', and 'serviceId'. Users asking about Linear tickets or issues would naturally use these terms. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with specific references to 'Linear', 'Apideck', 'serviceId "linear"', and the unified API pattern. Unlikely to conflict with other skills unless there's another Linear integration skill. | 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 solid connector skill that provides actionable code examples and good progressive disclosure to related resources. Its main weaknesses are moderate verbosity from repeated portability messaging and marketing language, and a lack of explicit validation workflows for a beta connector where coverage verification is critical. The entity mapping table and escape hatch pattern are particularly valuable.
Suggestions
Remove or condense the 'Portable across 6 Issue Tracking connectors' section — the portability point is already made in the intro and the code example adds little beyond what's shown in the minimal example.
Add an explicit coverage verification step with executable code (e.g., calling the `/connector/connectors/linear` endpoint) before the main examples, since this is a beta connector with partial coverage.
Trim the 'When to use this skill' section — Claude doesn't need to be told when to activate a skill about Linear; the numbered list restates what's already in the content.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill contains some unnecessary verbosity — the 'Portable across 6 Issue Tracking connectors' section repeats the portability pitch already made in the intro, and the 'When to use this skill' section over-explains activation context that Claude can infer. The marketing-style language ('compounding advantage') wastes tokens. However, the entity mapping table and coverage highlights are efficient. | 2 / 3 |
Actionability | Provides fully executable TypeScript examples for listing tickets, listing collection tickets, and a complete curl command for the Proxy API escape hatch. The entity mapping table and coverage highlights give concrete, specific guidance on what works and what doesn't, with clear fallback instructions. | 3 / 3 |
Workflow Clarity | The skill presents a reasonable flow (check coverage → use unified API → fall back to Proxy), but there's no explicit validation step or feedback loop. For a connector marked as beta with partial coverage, there should be an explicit 'verify coverage first' step with the actual command/code to check coverage before proceeding, rather than just mentioning it in passing. | 2 / 3 |
Progressive Disclosure | Excellent progressive disclosure with a clear overview in the skill itself and well-signaled one-level-deep references to SDK skills, OpenAPI specs, best practices, connector coverage tools, and official Linear docs. Content is appropriately split between this overview and referenced materials. | 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.