CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

create-pipeline-v1

Generate Harness v1 simplified Pipeline YAML using the new concise syntax with flat structure, ${{ }} expressions, script field, and action steps. Supports CI stages (run, run-test, background), CD stages (service/environment with action steps for K8s, Helm, ECS), approval (stage-level and inline), parallel execution, matrix/for/while strategies, caching, volumes, and templates. Use when asked for a v1 pipeline, simplified pipeline, new pipeline format, or when user specifically requests v1 syntax. Do NOT use for v0/standard pipelines (use create-pipeline). Trigger phrases: v1 pipeline, simplified pipeline, new pipeline format, create v1, modern pipeline syntax.

Quality

87%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

75%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.

A highly actionable reference: executable YAML for every construct, complete end-to-end examples, exact MCP call parameters, and real one-level-deep reference files for the bulk catalogs. The main cost is token duplication — the v0→v1 contrast rules and reference-consultation directives are repeated across Instructions, Key Differences, Performance Notes, and Troubleshooting.

Suggestions

Consolidate the v0→v1 contrast rules into the Key Differences table and remove their restatement in Instructions, Performance Notes, and Troubleshooting, which each repeat 'script: never command:', 'action: uses: not K8sRollingDeploy', and the ${{ }} vs <+...> rule.

State the 'consult references/v1-spec-schema.md and references/native-actions.md' directive once in the workflow (steps 3–4) instead of repeating it three further times in the Action Step section and Performance Notes.

Trim the inline step-type and action example gallery, leaving one representative pattern per step type inline and pointing to references/v1-spec-schema.md for the full catalog, to reduce the body's token footprint.

DimensionReasoningScore

Conciseness

Mostly efficient — every example is domain-specific v1 syntax Claude would not know, with no filler explaining general concepts — but the v0→v1 contrast rules are stated three to four times ("Use `script:` field in run steps, never `command:`" appears in Instructions, the Key Differences table, Performance Notes, and Troubleshooting) and the "consult references/v1-spec-schema.md" directive appears in three places. Not a 4 because this cross-section repetition is more than minor trimming; not a 2 because there is no padding with concepts Claude already knows.

3 / 5

Actionability

Fully executable guidance throughout: copy-paste-ready YAML for every step type (run, run-test, action, template, approval, background), complete CI and CD pipeline examples, and an exact MCP invocation ("resource_type: \"pipeline\"... body: { yamlPipeline: \"<full v1 pipeline YAML string>\" }") with concrete error-code fixes ("DUPLICATE_IDENTIFIER — Pipeline exists; use harness_update"). This matches the anchor-5 'copy-paste ready, covers the common cases' example.

5 / 5

Workflow Clarity

A clear six-step sequence (confirm v1 format → clarify requirements → consult spec → select native actions → generate YAML → optionally create via MCP) with a verification checkpoint before the risky MCP operation ("Verify the project exists" with harness_list) and error-recovery guidance in Troubleshooting. Not a 5 because the validation directive ("Validate all expressions use ${{ }} syntax before presenting") sits in Performance Notes rather than as an explicit step in the main workflow, leaving a minor checkpoint gap.

4 / 5

Progressive Disclosure

Structure is good: two real, substantive one-level-deep reference files (references/v1-spec-schema.md and references/native-actions.md) are clearly signaled at point of use ("Consult the spec reference - Use `references/v1-spec-schema.md` for the complete v1 schema... the full action catalog"), with the body holding key patterns and the bulk catalogs in the references. Not a 5 because the 465-line body duplicates catalog content (e.g., the action/template example gallery restated in Instructions and Step Types) that could be pushed to the references.

4 / 5

Total

16

/

20

Passed

Description

92%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: it names concrete capabilities with precise v1 syntax vocabulary, provides an explicit use-when clause plus an enumerated trigger-phrase list, and explicitly disambiguates against the v0 create-pipeline skill. The only weakness is slightly incomplete synonym coverage in its trigger phrases.

DimensionReasoningScore

Specificity

The description lists multiple specific concrete actions with comprehensive coverage: "Generate Harness v1 simplified Pipeline YAML using the new concise syntax with flat structure, ${{ }} expressions, script field, and action steps" plus enumerated capabilities ("CI stages (run, run-test, background)", "CD stages... for K8s, Helm, ECS", "approval (stage-level and inline)", "parallel execution, matrix/for/while strategies, caching, volumes, and templates"). Not a 4 because the gaps are negligible — the entire capability surface is named with concrete syntax terms rather than generic verbs.

5 / 5

Completeness

It clearly and explicitly answers both what ("Generate Harness v1 simplified Pipeline YAML..." with enumerated features) and when ("Use when asked for a v1 pipeline, simplified pipeline, new pipeline format, or when user specifically requests v1 syntax"), and adds a negative trigger ("Do NOT use for v0/standard pipelines"). This matches the anchor-5 pattern of concrete trigger phrases attached to both a what and a when, so a 4's 'could be more explicit' caveat does not apply.

5 / 5

Trigger Term Quality

Keyword coverage is good: it enumerates natural trigger phrases ("v1 pipeline, simplified pipeline, new pipeline format, create v1, modern pipeline syntax") that a user would plausibly say, and the "Use when asked for a v1 pipeline..." clause reinforces them. Not a 5 because a few natural variants are missing (e.g., "Harness pipeline", "concise pipeline", "flat pipeline syntax"); not a 3 because the explicit phrase list covers the common phrasings well rather than leaving only domain jargon.

4 / 5

Distinctiveness Conflict Risk

It carves a clear niche with minimal conflict risk by explicitly fencing off the sibling skill: "Do NOT use for v0/standard pipelines (use create-pipeline)" alongside v1-specific triggers. This is exactly the anchor-5 'clear niche with distinct triggers' pattern; a 4's 'minor overlap risk' is not evident since the v0/v1 boundary is stated explicitly.

5 / 5

Total

19

/

20

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 — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

harness/harness-ai

Path

plugins/claude/skills/create-pipeline-v1/SKILL.md

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.