gitlab-ci-patterns
Build GitLab CI/CD pipelines with multi-stage workflows, caching, and distributed runners for scalable automation. Use when implementing GitLab CI/CD, optimizing pipeline performance, or setting up automated testing and deployment.
66
78%
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 ./plugins/cicd-automation/skills/gitlab-ci-patterns/SKILL.mdQuality
Discovery
100%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 well-crafted skill description that clearly identifies the domain (GitLab CI/CD), lists specific capabilities (multi-stage workflows, caching, distributed runners), and provides explicit trigger guidance via a 'Use when' clause. It uses proper third-person voice and includes natural keywords that users would employ when seeking help with GitLab pipelines.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: building pipelines, multi-stage workflows, caching, distributed runners, and scalable automation. These are concrete, actionable capabilities. | 3 / 3 |
Completeness | Clearly answers both 'what' (build GitLab CI/CD pipelines with multi-stage workflows, caching, and distributed runners) and 'when' (explicit 'Use when' clause covering implementing GitLab CI/CD, optimizing pipeline performance, or setting up automated testing and deployment). | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'GitLab CI/CD', 'pipeline', 'caching', 'runners', 'automated testing', 'deployment', 'pipeline performance'. These cover common variations of how users would describe this need. | 3 / 3 |
Distinctiveness Conflict Risk | Clearly scoped to GitLab CI/CD specifically, which distinguishes it from generic CI/CD skills, GitHub Actions skills, or Jenkins skills. The GitLab-specific terminology (runners, .gitlab-ci.yml implied) makes it unlikely to conflict with other skills. | 3 / 3 |
Total | 12 / 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.
The skill provides highly actionable, copy-paste ready GitLab CI/CD patterns covering a broad range of use cases, which is its primary strength. However, it suffers from being a monolithic document that dumps all patterns inline without progressive disclosure, and lacks validation/error-recovery guidance for destructive operations like production deployments and Terraform applies. The best practices section is generic filler that doesn't add value for Claude.
Suggestions
Split advanced patterns (Terraform pipeline, security scanning, dynamic child pipelines) into separate referenced files to improve progressive disclosure and reduce token cost of the main SKILL.md
Add explicit validation and rollback steps for production deployments (e.g., what to do when `kubectl rollout status` fails, how to rollback with `kubectl rollout undo`)
Remove the 'Purpose', 'When to Use', and 'Best Practices' sections — the first two duplicate the frontmatter description, and the best practices are generic advice Claude already knows
Add a brief error-recovery feedback loop for the Terraform apply step (e.g., what happens if apply fails partially, how to recover state)
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient with concrete YAML examples, but includes some unnecessary sections like 'Purpose' and 'When to Use' that restate what's obvious from the title. The 'Best Practices' list at the end is generic advice Claude already knows. The sheer volume of examples (basic pipeline, Docker, multi-env, Terraform, security, caching, dynamic pipelines) makes this quite long without clear justification for including all patterns inline. | 2 / 3 |
Actionability | All examples are fully executable, copy-paste ready YAML configurations with specific image tags, concrete commands, and realistic variable usage. The patterns cover real-world scenarios with complete job definitions including artifacts, caching, environment configuration, and deployment strategies. | 3 / 3 |
Workflow Clarity | The pipeline stages are clearly sequenced (build → test → deploy), and the Terraform pipeline includes validate → plan → apply with manual gates. However, there are no explicit validation checkpoints or error recovery steps — for example, no guidance on what to do if `kubectl rollout status` fails, no feedback loops for failed deployments, and no rollback instructions for production deployments which are destructive operations. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of YAML examples with no content split into supporting files. The Terraform pipeline, security scanning, caching strategies, and dynamic pipelines could each be separate reference files. The 'Related Skills' section references other skills but doesn't offload any of its own bulk. For a skill this long (~200+ lines of content), the lack of any file decomposition is a significant organizational weakness. | 1 / 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
- wshobson/agents
- Commit
112197c
- 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.