fix-ci
Find failing PR checks, inspect logs or external check links, and apply focused fixes
52
57%
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 ./cursor-team-kit/skills/fix-ci/SKILL.mdQuality
Discovery
42%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description names concrete actions well but lacks a 'Use when...' clause, which is critical for Claude to know when to select this skill. It also misses common trigger terms like 'CI', 'pipeline', 'build failure', or 'GitHub Actions' that users would naturally use when encountering this scenario.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when a pull request has failing checks, CI/CD pipeline errors, or the user asks about build failures.'
Include common trigger term variations such as 'CI', 'CI/CD', 'pipeline', 'build failure', 'GitHub Actions', 'test failures', and 'status checks'.
Clarify the scope to reduce overlap with general debugging skills, e.g., specify that this is for GitHub/GitLab PR check failures specifically.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'Find failing PR checks', 'inspect logs or external check links', and 'apply focused fixes'. These are clear, actionable capabilities. | 3 / 3 |
Completeness | Describes what the skill does but has no explicit 'Use when...' clause or equivalent trigger guidance. Per the rubric, a missing 'Use when...' clause caps completeness at 2, and since the 'when' is entirely absent (not even implied strongly), this scores at 1. | 1 / 3 |
Trigger Term Quality | Includes relevant terms like 'PR checks', 'logs', 'failing', and 'fixes', but misses common user variations such as 'CI', 'pipeline', 'build failure', 'GitHub Actions', 'test failures', or 'CI/CD'. | 2 / 3 |
Distinctiveness Conflict Risk | The focus on PR checks and logs is somewhat specific, but 'apply focused fixes' is broad enough to overlap with general debugging or code-fixing skills. The PR context helps but isn't fully distinctive without more explicit scoping. | 2 / 3 |
Total | 8 / 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.
A concise, well-structured skill that clearly defines the CI-fixing workflow at a high level. Its main weakness is the lack of concrete, actionable examples—such as how to parse log output, common error patterns and their fixes, or specific commands for inspecting GitHub Actions logs. The workflow would also benefit from explicit validation steps before pushing fixes.
Suggestions
Add concrete examples of inspecting logs, e.g., `gh run view <run-id> --log-failed` and a sample error output with the corresponding fix approach.
Include a validation checkpoint before pushing, such as running the failing command locally or checking syntax, to prevent fix-introduces-new-failure loops.
Add 1-2 example patterns of common CI failures (e.g., lint error, test failure, type error) with minimal fix examples to make the guidance more actionable.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Every line earns its place. No unnecessary explanations of what CI is, how GitHub works, or what PR checks are. Assumes Claude's competence throughout. | 3 / 3 |
Actionability | Provides a concrete command (`gh pr checks --json name,bucket,state,workflow,link`) which is good, but the rest of the workflow is described at a high level ('apply the smallest safe fix', 'extract the first actionable error') without concrete examples of how to inspect logs, parse errors, or what specific fix patterns look like. | 2 / 3 |
Workflow Clarity | The 4-step workflow is clearly sequenced with an explicit iteration loop (push, re-check, repeat until green), but lacks validation checkpoints or error recovery guidance. For example, there's no guidance on what to do if a fix introduces new failures, or how to verify a fix locally before pushing. | 2 / 3 |
Progressive Disclosure | This is a simple, single-purpose skill under 50 lines with well-organized sections (Trigger, Workflow, Guardrails, Output). No external references are needed for this scope, and the structure is clean and navigable. | 3 / 3 |
Total | 10 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- cursor/plugins
- Commit
b8f2564
- 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.