Fetch CI build results and diagnose failures. Auto-detects provider from project files or URLs. Supports GitHub Actions, Buildkite, and CircleCI.
74
62%
Does it follow best practices?
Impact
92%
1.67xAverage score across 3 eval scenarios
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./tests/ext_conformance/artifacts/agents-mikeastock/skills/fetch-ci-build/SKILL.mdQuality
Discovery
67%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 communicates what the skill does with specific actions and named CI providers, making it distinctive. However, it lacks an explicit 'Use when...' clause, which caps completeness, and could benefit from more natural trigger terms that users would actually say when encountering CI issues.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user asks about CI failures, build errors, pipeline issues, or wants to check the status of a CI run.'
Include additional natural trigger terms like 'pipeline', 'build failed', 'CI/CD', 'workflow run', 'build logs', or 'why did my build fail' to improve keyword coverage.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple concrete actions: 'Fetch CI build results', 'diagnose failures', 'Auto-detects provider from project files or URLs'. Also names three specific providers (GitHub Actions, Buildkite, CircleCI). | 3 / 3 |
Completeness | Clearly answers 'what does this do' (fetch CI build results, diagnose failures, auto-detect provider), but lacks an explicit 'Use when...' clause specifying when Claude should select this skill. The 'when' is only implied. | 2 / 3 |
Trigger Term Quality | Includes good terms like 'CI', 'build results', 'failures', 'GitHub Actions', 'Buildkite', 'CircleCI', but misses common user phrases like 'pipeline', 'build failed', 'CI/CD', 'workflow run', 'build logs', or 'why did my build fail'. | 2 / 3 |
Distinctiveness Conflict Risk | The description carves out a clear niche around CI build results and failure diagnosis with specific provider names. It is unlikely to conflict with other skills due to the specificity of CI providers and the build diagnosis focus. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
57%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill has good structure and progressive disclosure, with clear provider-specific references and a well-organized overview. However, it lacks concrete executable commands for the core fetch-and-diagnose workflow, delegating almost all actionable details to reference files. The graphviz diagram adds token cost without rendering value, and the step-by-step section largely restates the diagram in prose without adding concrete guidance.
Suggestions
Add at least one concrete executable example per provider in the main skill (e.g., `gh run view <run-id> --log-failed`) so the skill is actionable even before loading reference files.
Remove or significantly condense the graphviz dot diagram - Claude cannot render it, and the step-by-step section already covers the same flow.
Add an explicit verification step to the workflow (e.g., 'After applying fix, run tests locally: `<test command>` to confirm the fix before pushing').
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill includes some unnecessary verbosity - the graphviz dot diagram is a nice idea but adds significant tokens for something Claude can't render, and the step-by-step process largely repeats what the diagram already conveys. The tables are efficient, but the overall content could be tightened. | 2 / 3 |
Actionability | The skill provides some concrete guidance (bash detection commands, provider table) but the core workflow steps (3-7) are vague - 'Use the provider-specific commands to fetch build information' delegates all actual execution details to reference files without showing any concrete commands or code. The skill describes what to do rather than showing how. | 2 / 3 |
Workflow Clarity | The workflow is clearly sequenced with numbered steps and a decision flow, and includes an interactive checkpoint (asking the user what to do). However, there are no validation steps for verifying that fixes actually resolve the failures - no 're-run CI' or 'run tests locally' step is explicitly part of the workflow sequence, only mentioned as an integration with another skill. | 2 / 3 |
Progressive Disclosure | Excellent progressive disclosure - the SKILL.md serves as a clear overview with well-signaled one-level-deep references to provider-specific files (references/github.md, references/buildkite.md, references/circleci.md) and cross-references to related skills. Content is appropriately split between overview and detail. | 3 / 3 |
Total | 9 / 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.
6e3d68c
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.