CtrlK
BlogDocsLog inGet started
Tessl Logo

pipeline-blueprint

Provide CI/CD best practices and pipeline templates for GitHub Actions and GitLab CI, recommending configurations based on project type (frontend, backend, fullstack, library, monorepo, mobile). Trigger when users ask about setting up CI/CD, automating builds, improving pipelines, or mention keywords like GitHub Actions, GitLab CI, pipeline templates, or deployment automation.

63

Quality

75%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./skills/pipeline-blueprint/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

67%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body delivers highly actionable, complete pipeline templates with a clear selection workflow and a useful decision table. Its weaknesses are the opposite trade-off: a monolithic 652-line file with no progressive disclosure, where most template bulk could live in reference files, plus no validation step for generated pipelines.

Suggestions

Move the six per-project-type pipeline templates into separate files under references/ (e.g., references/frontend.md, references/backend.md), keeping SKILL.md as a concise overview with the best-practices checklist, decision table, and clearly signaled links.

Add a validation step to the workflow, such as checking generated YAML with actionlint (GitHub Actions) or `glab ci lint` (GitLab), before presenting it to the user.

Trim boilerplate steps that Claude already knows (e.g., repeated checkout/setup-node blocks) down to the differentiating configuration per template.

DimensionReasoningScore

Conciseness

The prose is lean with no concept over-explanation, but ~550 of 652 lines are complete boilerplate pipeline YAML that Claude can largely generate from general knowledge; only the curation (which template per project type, pinned versions, caching choices) is net-new. This matches anchor 3 ("mostly efficient but... could be tightened"), since the verbosity is bulk boilerplate rather than the over-explanation of anchor 2 or the leanness of anchor 4.

3 / 5

Actionability

The templates are complete, copy-paste-ready YAML: pinned runner images and action versions, matrix strategies, service containers, caching configuration, artifact upload, and branch rules are all fully specified. The only placeholders are deploy commands, which are explicitly commented as user-specific substitutions ("# Replace with your deployment step"), matching anchor 5's "copy-paste ready code or commands".

5 / 5

Workflow Clarity

"When a user describes their project (language, framework, deployment target), recommend the most appropriate pipeline template below. Adapt stages, caching strategies, and deployment steps to match their stack" gives a clear sequence, reinforced by the decision-guide table mapping project traits to templates. It is anchor 4 rather than 5 because there is no validation checkpoint (e.g., linting the generated YAML with actionlint or glab ci lint) after assembling a pipeline.

4 / 5

Progressive Disclosure

No references/, scripts/, or assets/ files exist, and all six project-type templates plus advanced patterns are inlined in a single 652-line SKILL.md. That matches anchor 2 ("content that clearly belongs in separate files is inlined") — each per-project-type template is a natural references/ file. It is not 3 because there are no references at all to signal, and the internal section headers, while good, do not offset the monolithic inlining.

2 / 5

Total

14

/

20

Passed

Description

83%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description: concrete third-person capability statement, explicit trigger clause with natural keywords, and a clear platform niche. The main weaknesses are missing common trigger synonyms (continuous integration, build pipeline) and slight overlap risk from broad deployment-related triggers.

Suggestions

Add common trigger synonyms such as "continuous integration", "build pipeline", or "CI configuration" to the trigger clause.

Narrow the broadest triggers ("deployment automation", "automating builds") toward pipeline-configuration intent to reduce overlap with deployment/hosting skills.

DimensionReasoningScore

Specificity

"Provide CI/CD best practices and pipeline templates for GitHub Actions and GitLab CI, recommending configurations based on project type (frontend, backend, fullstack, library, monorepo, mobile)" lists several concrete actions with an enumerated scope, matching anchor 4. It is not 5 because coverage has minor gaps (e.g., nothing about auditing or migrating existing pipelines), and not 3 because it goes beyond 1-2 actions with the full project-type enumeration.

4 / 5

Completeness

It clearly answers what ("Provide CI/CD best practices and pipeline templates... recommending configurations based on project type") and explicitly answers when with concrete trigger phrases ("Trigger when users ask about setting up CI/CD, automating builds, improving pipelines, or mention keywords like GitHub Actions, GitLab CI..."), matching the anchor-5 example structure exactly.

5 / 5

Trigger Term Quality

"setting up CI/CD, automating builds, improving pipelines, GitHub Actions, GitLab CI, pipeline templates, deployment automation" gives good natural keyword coverage users would actually say. It falls short of anchor 5 because common variants like "continuous integration", "build pipeline", or "CI config" are missing.

4 / 5

Distinctiveness Conflict Risk

The CI/CD niche anchored to GitHub Actions and GitLab CI is distinct, but broad triggers like "deployment automation" and "automating builds" create minor overlap risk with deployment/hosting/container skills, matching anchor 4 ("mostly distinct; minor overlap risk") rather than 5's minimal conflict risk.

4 / 5

Total

17

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (652 lines); consider splitting into references/ and linking

Warning

Total

15

/

16

Passed

Repository
zebbern/claude-code-guide
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.