CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

fix-ci-tests

Diagnose and fix CI failures on a GitHub PR by analyzing failing checks, reading logs, and applying fixes

63

Quality

79%

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

Fix and improve this skill with Tessl

tessl review fix ./.claude/skills/fix-ci-tests/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

85%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.

A highly actionable, well-sequenced workflow with strong validation and feedback loops — near the top of the actionability and workflow-clarity anchors. Its main weakness is monolithic structure: long, conditional sub-procedures (GraphQL comment resolution, fuzz corpus handling) are inlined rather than offloaded to one-level-deep reference files.

Suggestions

Move step 9's GraphQL reply/resolve queries into a reference file (e.g. references/resolve-comments.md) and keep only the trigger condition and a pointer inline, since that step only runs when review comments exist.

Consider offloading the CI job matrix and fuzz-corpus workflow to short reference files so SKILL.md stays a lean overview.

Consolidate the untrusted-data security guidance into one authoritative callout instead of restating it in the header, step 2, and step 9.

DimensionReasoningScore

Conciseness

The body is efficient and dense with repo-specific facts Claude cannot know (CI job matrix, env-var test commands, corpus file paths), with only minor over-explanation — the untrusted-data security note is stated three times and step 9's inline GraphQL queries are lengthy. Not 5 because those spots could be trimmed without losing clarity.

4 / 5

Actionability

Fully executable, copy-paste-ready commands throughout: `gh pr checks`, `gh run view <run-id> --log-failed`, `go test -race` invocations, the docker bash-comparison one-liner, and the commit/push sequence, each covering a common failure case. No pseudocode; placeholders like `<run-id>` and `{owner}` are appropriately parameterized.

5 / 5

Workflow Clarity

A clear 10-step sequence with explicit validation checkpoints: reproduce failures locally before fixing (step 4), run the full suite to verify (step 7), and an explicit feedback loop ('If new failures appear, repeat from step 4') before the destructive push step. It also includes a concrete example of fuzz failure output to anchor log interpretation.

5 / 5

Progressive Disclosure

Sections and headers are well organized, but all ~275 lines live in SKILL.md with no reference files — path-specific detail that only some runs need (step 9's GraphQL thread-resolution queries, the CI job matrix, the fuzz-corpus workflow) is inlined. This fits 'content that should be separate is inline' better than the 'most content appropriately placed' anchor 4.

3 / 5

Total

17

/

20

Passed

Description

66%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 clear, concise description with concrete actions and good natural keywords, but it lacks any 'when to use' trigger clause, which caps completeness. Adding a 'Use when...' clause with synonyms like 'build failures' or 'failing checks on a PR' would raise both completeness and trigger coverage.

Suggestions

Add a 'Use when...' clause, e.g. 'Use when CI checks fail on a pull request, the user mentions build failures or red CI, or asks to fix failing tests on a PR.'

Include common trigger synonyms such as 'build failure', 'tests failing', and 'red X checks' to broaden natural keyword coverage.

Briefly signal scope boundaries (e.g. whether it handles flaky-test triage and review-comment resolution) to sharpen distinctiveness against sibling test-fixing skills.

DimensionReasoningScore

Specificity

Names the domain ("CI failures on a GitHub PR") and three concrete actions ("analyzing failing checks, reading logs, and applying fixes"), matching the 'several specific actions; minor gaps' anchor. Not 5 because coverage omits later workflow capabilities like verification, committing, and pushing.

4 / 5

Completeness

The 'what' is clearly and concretely stated, but there is no 'Use when...' clause or equivalent explicit trigger guidance, which the rubric caps at 3. Not 4 because the 'when' is entirely absent rather than merely imprecise.

3 / 5

Trigger Term Quality

Natural phrases users would say — "CI failures", "GitHub PR", "failing checks", "logs" — give good keyword coverage. Not 5 because common variations like "build failure", "tests failing", or "red CI" are missing; not 3 since the included terms are natural rather than jargon-only.

4 / 5

Distinctiveness Conflict Risk

The CI-failure-on-a-PR niche is mostly distinct with clear domain terms, risking only minor overlap with closely related test-fixing skills. Not 5 because no trigger phrase further sharpens the niche against those siblings.

4 / 5

Total

15

/

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.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository

DataDog/rshell

Path

.claude/skills/fix-ci-tests/SKILL.md

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.