Linear Multiworkspace 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 Multiworkspace. Routes through Apideck with serviceId "linear-multiworkspace".
71
66%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./connectors/linear-multiworkspace/SKILL.mdQuality
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 skill description that clearly identifies its niche (Linear Multiworkspace via Apideck), includes an explicit 'Use when' clause with natural trigger terms, and is highly distinctive. The main weakness is that the specific capabilities could be more granular — listing concrete actions beyond 'read, write, or comment' would strengthen the specificity dimension.
Suggestions
Expand the action list to be more specific, e.g., 'create issues, update statuses, assign users, add comments, list tickets' instead of the general 'read, write, or comment on tickets'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (issue tracking via Linear Multiworkspace) 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, etc. | 2 / 3 |
Completeness | Clearly answers both 'what' (Linear Multiworkspace integration via Apideck's Issue Tracking unified API for reading, writing, and commenting on tickets) and 'when' (explicit 'Use when the user wants to read, write, or comment on tickets and issues in Linear Multiworkspace'). | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms: 'tickets', 'issues', 'Linear Multiworkspace', 'comment', 'read', 'write', 'Issue Tracking', and 'Apideck'. Users asking about Linear issues or tickets would naturally use these terms. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with specific identifiers: 'Linear Multiworkspace', 'Apideck', and 'serviceId linear-multiworkspace'. This is clearly distinguishable from other issue tracking skills or other Linear connectors. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill has excellent progressive disclosure and structure, with clear references to related skills and external documentation. However, it suffers from significant verbosity — marketing-style explanations of Apideck's value proposition, redundant descriptions of concepts Claude already understands, and sections that don't add actionable value. The actionable content (code examples, curl commands) is decent but could cover more operations.
Suggestions
Remove marketing/value-proposition content like the 'compounding advantage' paragraph and the verbose explanation of what Apideck handles — reduce to just the serviceId, API surface, and code examples.
Cut the 'When to use this skill' section down to 1-2 lines; Claude doesn't need detailed activation criteria explained at length.
Add concrete examples for creating a ticket and adding a comment, and replace the proxy placeholder '<target endpoint on Linear Multiworkspace>' with a real Linear API endpoint example.
Integrate coverage verification into an explicit workflow: 1. Check coverage → 2. If supported, use unified API → 3. If UnsupportedOperationError, use proxy with specific endpoint — with error handling code.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Significant verbosity throughout. The 'Portable across 6 connectors' section is marketing copy Claude doesn't need. Explanations of what Apideck does (handles auth, pagination, rate limiting), what Vault does, and the 'compounding advantage' paragraph are unnecessary filler. The 'When to use this skill' section over-explains activation criteria. Much of this content explains concepts Claude can infer from a minimal example. | 1 / 3 |
Actionability | The TypeScript example is executable and copy-paste ready, and the curl commands for coverage verification and proxy are concrete. However, the skill lacks examples for common operations beyond listing tickets (e.g., creating a ticket, adding a comment), and the proxy example has a placeholder '<target endpoint>' without a concrete Linear-specific URL. | 2 / 3 |
Workflow Clarity | There's an implicit workflow: check coverage → use unified API → fall back to proxy if unsupported. However, there's no explicit validation step or error handling sequence. The coverage check is mentioned but not integrated into a clear decision workflow with feedback loops for handling UnsupportedOperationError. | 2 / 3 |
Progressive Disclosure | Well-structured with clear sections and one-level-deep references to SDK skills, best practices, connector coverage, and external docs. Navigation is easy with clearly signaled links to related skills and external resources. Content is appropriately split between this overview and referenced materials. | 3 / 3 |
Total | 8 / 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.