CtrlK
BlogDocsLog inGet started
Tessl Logo

gitlab-api

Fetches and analyzes GitLab merge request (MR) comments, metadata, and review feedback using authenticated API calls. Capabilities include fetching comment threads, retrieving reviewer feedback, filtering unresolved discussions, and generating MR activity reports. Use when the user asks about GitLab MR comments, code review discussions, review feedback, approval status, troubleshooting review delays, or needs to fetch merge request metadata via the GitLab API.

67

Quality

81%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

SKILL.md
Quality
Evals
Security

Quality

Content

63%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is well-structured and largely executable, with a genuinely valuable GitLab-specific mindset (System vs. Type axes, 200-with-error-body) and concrete script documentation. Its weaknesses are systematic redundancy (WHY/Consequence pairs, double System/Type explanation, duplicate reference link) and broken navigation — all five eval-scenario links point to nonexistent files.

Suggestions

Remove the five Eval Scenarios links to evals/scenario-*/task.md (the files do not exist in the bundle) or add the evals directory, so navigation matches the actual bundle structure.

Merge each anti-pattern's WHY and Consequence into a single line of rationale — they currently restate the same failure mode in four consecutive sections (token exposure, pagination truncation, 429 mishandling, v3 404s).

State the System/Type distinction once — either in Mindset or in Critical Pitfalls — instead of explaining it twice, and drop the one-row References table that duplicates the "Common Workflows and Error Handling" section link.

DimensionReasoningScore

Conciseness

Mostly GitLab-specific and efficient (the System/Type two-axis explanation is genuinely load-bearing), but there is systematic, repeated tightening opportunity: each of the four anti-patterns carries both a WHY paragraph and a Consequence paragraph that largely restate each other (e.g. pagination WHY "silently truncate downstream analysis" vs. Consequence "silently omit older or later comments"), the System/Type distinction is explained twice (Mindset plus the first Critical Pitfall that says "see Mindset"), and the workflows reference is linked twice (section link plus a one-row References table). This matches 'Mostly efficient but includes some unnecessary explanation or could be tightened'; not 4 because the duplication is structural across multiple sections rather than a few minor trimmable spots, and not 2 because nothing explains concepts Claude already knows at length.

3 / 5

Actionability

The primary path is fully executable — "scripts/get_mr_comments.sh \"https://gitlab.com/your-group/your-project/-/merge_requests/123\"" with a documented output format, exit codes, and the copy-paste-ready "${GITLAB_TOKEN:?Set GITLAB_TOKEN with read_api scope}" guard — and the pagination example is a runnable shell loop. Not 5: minor gaps remain — the rate-limit guidance ("check for `429` status codes and implement exponential backoff") is prose rather than code, and the pagination example uses an undefined "$API_URL" and generic "merge_requests" endpoint rather than the MR-comments context this skill wraps.

4 / 5

Workflow Clarity

The core action is unambiguous (script invocation, documented output shape, exit codes 0/1) and validation is explicitly required ("Validate responses before processing — the API can return `200 OK` with an error body"), with the multi-step review-summary and progress-tracking workflows sequenced and given explicit validation checkpoints in the referenced file (e.g. "grep -q \"Author:\" || { echo \"Invalid response\"; exit 1; }"). Not 5: those sequenced, validated workflows live in the reference rather than the body, and the body itself never lays out even a compact end-to-end sequence (fetch → validate → filter → report) inline, leaving the reader to assemble it from the Mindset, pitfalls, and reference link.

4 / 5

Progressive Disclosure

Structure is good and the one real reference (references/workflows-and-error-handling.md) is clearly signaled and one level deep, but the Eval Scenarios section links five files — evals/scenario-1..5/task.md — that do not exist in the bundle, and the single-row References table merely duplicates the earlier "Common Workflows" section link. Per the guideline to score against the actual bundle structure, five broken navigation paths plus the redundant duplicate link fit 'references present but not clearly signaled / could be better organized' better than the 'minor organization gaps' of a 4.

3 / 5

Total

14

/

20

Passed

Description

100%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description that hits the top anchor on every dimension: concrete capability list, comprehensive natural-language triggers with synonyms, explicit what-and-when structure, and a tightly scoped GitLab-MR niche. The only improvement opportunity is trimming the mild redundancy between the opening sentence and the 'Capabilities include' sentence, which restates fetching and reviewer feedback.

DimensionReasoningScore

Specificity

Lists four concrete, distinct actions — "fetching comment threads, retrieving reviewer feedback, filtering unresolved discussions, and generating MR activity reports" — which comprehensively cover the skill's capability surface, matching the anchor 'Lists multiple specific concrete actions; comprehensive coverage'. Not 4: there are no coverage gaps; the only flaw is mild redundancy between sentences 1 and 2 ("review feedback" / "retrieving reviewer feedback"), which is a verbosity nit rather than missing specificity.

5 / 5

Completeness

Explicitly answers both questions: 'what' via "Fetches and analyzes GitLab merge request (MR) comments, metadata, and review feedback using authenticated API calls" plus the capabilities sentence, and 'when' via the concrete "Use when the user asks about..." trigger list. This mirrors the anchor-5 example structure exactly; not 4 because the 'when' clause is already fully explicit with concrete trigger phrases.

5 / 5

Trigger Term Quality

The 'Use when' clause covers natural phrasings users would actually say — "GitLab MR comments, code review discussions, review feedback, approval status, troubleshooting review delays" — and includes synonyms ("merge request (MR)" gives both the abbreviation and the full term; comments/discussions/feedback all appear). Matches the comprehensive-synonyms anchor; not 4 because no commonly-used variation for this domain is missing (there is no relevant file extension for an API-based skill).

5 / 5

Distinctiveness Conflict Risk

Clear niche — GitLab merge request comment/metadata retrieval — with platform-specific triggers ("GitLab MR", "merge request", "GitLab API") that would not fire for PDF, document, or generic code-review skills. Not 4: the scope is tightly bounded to MR discussions and does not claim adjacent territory (issues, CI/CD) that would create overlap risk with related GitLab skills.

5 / 5

Total

20

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

relative_links

Relative link issues: 5 missing, 5 deeper-than-1-level

Warning

Total

15

/

16

Passed

Repository
pantheon-org/tekhne
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.