gitlab
GitLab 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 GitLab. Routes through Apideck with serviceId "gitlab".
83
81%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Advisory
Suggest reviewing before use
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 (GitLab via Apideck), specifies the domain (issue tracking), and includes an explicit 'Use when' clause with natural trigger terms. Its main weakness is that the specific capabilities could be more granular — listing concrete actions like 'create issues, list issues, add comments, update status' would strengthen it. The mention of the unified API pattern and serviceId switching is useful context for skill selection.
Suggestions
Expand the capability list with more specific actions like 'create issues, list issues, update issue status, add/list comments, manage labels' to improve specificity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (GitLab issue tracking) and some actions ('read, write, or comment on tickets and issues'), but doesn't list comprehensive specific actions like creating issues, closing issues, listing labels, assigning users, etc. | 2 / 3 |
Completeness | Clearly answers both 'what' (GitLab integration via Apideck's Issue Tracking unified API for reading, writing, commenting on tickets/issues) and 'when' ('Use when the user wants to read, write, or comment on tickets and issues in GitLab') with explicit trigger guidance. | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'GitLab', 'tickets', 'issues', 'comment', 'read', 'write'. Also includes technical identifiers like 'serviceId' and 'Apideck' that help with routing. Good coverage of terms a user would naturally use. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — specifies GitLab specifically, routes through Apideck with serviceId 'gitlab', and is clearly scoped to issue tracking. Unlikely to conflict with other skills unless there's another GitLab issue tracking 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 well-structured connector skill with strong actionability through executable examples and a clear entity mapping table. Its main weaknesses are some marketing-style verbosity about Apideck's portability benefits and missing validation/error-handling guidance for a beta connector. The progressive disclosure and reference structure are excellent.
Suggestions
Trim the 'Portable across 6 Issue Tracking connectors' section to just the code example showing serviceId swapping — remove the marketing paragraph about 'compounding advantage'.
Add a brief error handling or validation step, e.g., how to check if a specific operation is supported before calling it, especially given the beta status and 'occasional mapping gaps' caveat.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill includes some unnecessary verbosity — the 'Portable across 6 Issue Tracking connectors' section over-explains the value proposition of Apideck (which is marketing, not actionable guidance), and the 'When to use this skill' section explains things Claude can infer. However, the entity mapping table and coverage highlights are efficient and useful. | 2 / 3 |
Actionability | Provides fully executable TypeScript examples for listing tickets, filtering by collection, 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's supported vs. what requires the Proxy. | 3 / 3 |
Workflow Clarity | The skill covers the happy path well (list tickets, filter by project, use proxy for unsupported operations) but lacks explicit validation steps or error handling guidance. For a connector marked as beta with 'occasional mapping gaps,' there should be a clearer workflow for verifying coverage and handling failures. | 2 / 3 |
Progressive Disclosure | Excellent structure with a concise overview, quick facts, minimal examples inline, and well-signaled one-level-deep references to SDK skills, OpenAPI specs, best practices, and connector coverage tools. The 'See also' section provides clear navigation without nesting. | 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.