fetch-ci-build
Fetch CI build results and diagnose failures. Auto-detects provider from project files or URLs. Supports GitHub Actions, Buildkite, and CircleCI.
69
55%
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 and names specific CI providers, giving it strong specificity and distinctiveness. However, it lacks an explicit 'Use when...' clause which would help Claude know exactly when to select it, and it could benefit from more natural trigger terms users might 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 supported. | 3 / 3 |
Completeness | Clearly answers 'what does this do' (fetch CI 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 phrasings like 'pipeline', 'build failed', 'CI/CD', 'workflow run', 'build logs', or 'why did my build fail'. | 2 / 3 |
Distinctiveness Conflict Risk | Very clearly scoped to CI build results and failure diagnosis with three named providers. This is a distinct niche unlikely to conflict with other skills. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill has strong structural organization and good progressive disclosure with provider-specific details properly delegated to reference files. However, it critically lacks actionable, executable content - the main skill reads more like a process description than concrete instructions Claude can follow. The workflow is well-sequenced but missing verification steps after applying fixes.
Suggestions
Add at least one concrete, executable example for each provider showing the actual fetch command and how to parse failure output (e.g., `gh run view <run-id> --log-failed` for GitHub Actions)
Add a verification step after applying fixes: re-run the failing test locally or trigger a new CI build to confirm the fix works
Remove the graphviz dot diagram - it duplicates the step-by-step process section and consumes significant tokens for a format that isn't directly useful to Claude
Make Step 5 'Present Findings' more concrete with an example of what the output should look like (e.g., a sample failure report with file, line, error, and proposed fix)
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill includes some unnecessary verbosity - the graphviz dot diagram is a nice idea but consumes many tokens for something Claude can infer from the step-by-step list. The step-by-step process section largely restates what the diagram already shows. Some sections like 'Common Mistakes' and 'Error Types Detected' add value but could be tighter. | 2 / 3 |
Actionability | The skill lacks concrete, executable commands for the core task. Steps 3-5 say 'use provider-specific commands' without showing any actual commands. The auto-detection bash snippets are the only executable code, and they're trivial. The actual fetching, parsing, and diagnosing is entirely delegated to reference files without any concrete examples shown here. | 1 / 3 |
Workflow Clarity | The workflow is clearly sequenced with both a diagram and numbered steps, and includes decision points (apply fix vs investigate). However, there are no explicit validation checkpoints - no verification that the fix actually resolves the CI failure, no step to re-run CI after applying fixes, and the 'ask user' step is more of a menu than a validation gate. | 2 / 3 |
Progressive Disclosure | Excellent use of progressive disclosure - the main skill provides a clear overview and workflow, with provider-specific details properly delegated to one-level-deep reference files (references/github.md, references/buildkite.md, references/circleci.md). References are clearly signaled and well-organized. | 3 / 3 |
Total | 8 / 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
47823e3
- 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.