fetch-ci-build
Fetch CI build results and diagnose failures. Auto-detects provider from project files or URLs. Supports GitHub Actions, Buildkite, and CircleCI.
67
51%
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, giving it strong specificity and distinctiveness. 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 more natural trigger terms users would say, such as 'pipeline', 'build failed', 'CI/CD', 'workflow run', 'build logs', 'why did my build fail', or 'check CI status'.
| 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 | Very clear niche focused on CI build results and failure diagnosis across three named providers. Unlikely to conflict with other skills due to the specific CI/build domain and named platforms. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
35%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides a well-structured overview of a multi-provider CI diagnosis workflow with good organization and clear provider detection logic. However, it falls short on actionability—the core operations (fetching builds, parsing failures, proposing fixes) are described abstractly rather than with concrete commands or code. The absence of bundle files means the referenced provider guides don't exist, leaving the skill incomplete.
Suggestions
Add concrete, executable examples for at least one provider (e.g., show actual `gh run view` commands for GitHub Actions with output parsing)
Include a real example of failure output and the corresponding proposed fix to make the diagnosis workflow tangible
Provide the referenced bundle files (references/github.md, etc.) or inline the essential provider-specific commands so the skill is self-contained
Remove the dot graph (not renderable in Claude's context) and consolidate the workflow into the step-by-step section to reduce redundancy
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill includes some unnecessary elements like the dot graph (which Claude can't render and adds visual noise), and the step-by-step process largely restates what the workflow diagram already conveys. The tables are efficient, but overall there's redundancy between the workflow diagram and the textual steps. | 2 / 3 |
Actionability | The skill lacks concrete, executable commands for the core operations. Steps 3-5 say 'use provider-specific commands' without showing any actual commands. The auto-detection bash snippets are the only executable code, and the actual fetching/diagnosis logic is entirely deferred to reference files that aren't provided in the bundle. | 1 / 3 |
Workflow Clarity | The multi-step process is clearly sequenced with numbered steps and includes a decision flow for handling failures vs. passing builds. However, there are no explicit validation checkpoints (e.g., verifying auth works before fetching, confirming the fix compiles before moving on), and the steps are too abstract to guide actual execution reliably. | 2 / 3 |
Progressive Disclosure | The skill references three provider-specific files (references/github.md, references/buildkite.md, references/circleci.md) which is good structure, but no bundle files were provided, meaning these references are broken. The main file also contains content that could be more concise if the referenced files actually existed and carried the detail. | 2 / 3 |
Total | 7 / 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
- Dicklesworthstone/pi_agent_rust
- Commit
99da384
- 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.