CtrlK
BlogDocsLog inGet started
Tessl Logo

create-service

Generate Harness Service YAML for deployable workloads and create via MCP. Supports Kubernetes, Helm, ECS, Serverless, SSH, and WinRm deployment types with artifact sources from Docker Hub, ECR, GCR, ACR, Nexus, and S3. Use when asked to create a service, define a Kubernetes service, set up a Helm chart deployment, configure an ECS service, or define what gets deployed. Trigger phrases: create service, service definition, Kubernetes service, Helm service, ECS service, deployment service, artifact source.

68

Quality

82%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No known issues

SKILL.md
Quality
Evals
Security

Quality

Content

65%

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

The body is highly actionable with executable YAML and concrete MCP calls, but it is verbose due to repeated full-example blocks across deployment types and lacks a post-creation validation checkpoint. Progressive disclosure is weak because everything is inline in one monolithic file with no local reference files.

Suggestions

De-duplicate the per-type YAML examples: keep the full 'Service Structure' sample, then show only the differentiating spec fields for Helm, Kustomize, ECS, and Serverless instead of repeating the entire artifacts block each time.

Add an explicit validation step to the workflow after the harness_create call (e.g. call harness_list or verify the returned identifier) before declaring the service created, turning the sequence into a validate-then-confirm feedback loop.

Split the deployment-type examples and the artifact-source spec table into a references/ file (e.g. references/deployment-types.md) and link to it from SKILL.md, so the main file stays a concise overview with clearly signaled one-level-deep references.

DimensionReasoningScore

Conciseness

Mostly efficient with no concept-explanation padding, but the five per-type YAML examples repeat the full artifacts/manifests block with only minor variations (e.g. the Kubernetes example duplicates the earlier "Service Structure" sample), so it could be tightened by showing only the differing spec.

2 / 3

Actionability

Provides fully executable YAML and concrete MCP invocations with named parameters ("harness_create", resource_type "service", org_id, project_id, body) plus an enumerated artifact-source spec table — copy-paste ready, matching the executable anchor.

3 / 3

Workflow Clarity

A clear numbered 5-step sequence with a user-confirmation checkpoint exists, but there is no post-creation validation/verification step; per the rubric's scoring note, a resource-creating operation missing a verify step caps workflow clarity at 2 rather than 3.

2 / 3

Progressive Disclosure

Sections are well-organized, but all content lives inline in a single ~265-line file with no local bundle references (references/, scripts/, assets/ absent); the one cross-reference points to another skill's create-pipeline/references/codebase-analysis.md rather than a clearly signaled one-level-deep local file.

2 / 3

Total

9

/

12

Passed

Description

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.

The description is specific, trigger-rich, and complete, cleanly stating what the skill does and when to invoke it with concrete deployment-type and artifact-source enumeration. It is third-person, concise, and unlikely to conflict with sibling skills.

DimensionReasoningScore

Specificity

Lists multiple concrete actions — "Generate Harness Service YAML ... and create via MCP" — plus enumerated deployment types and artifact sources, matching the multi-action anchor rather than the single-domain anchor at 2.

3 / 3

Completeness

Explicitly answers both what ("Generate Harness Service YAML ... create via MCP" with supported types/sources) and when ("Use when asked to create a service, define a Kubernetes service...") with explicit triggers, satisfying the both-what-and-when anchor.

3 / 3

Trigger Term Quality

Natural user phrasing is well covered via "Trigger phrases: create service, service definition, Kubernetes service, Helm service, ECS service, deployment service, artifact source" plus a "Use when asked to..." clause; these are terms a user would actually say.

3 / 3

Distinctiveness Conflict Risk

Has a clear niche (Harness service definitions) with triggers tied specifically to service creation, making it unlikely to fire for unrelated skills; not the generic/overlapping anchor at 2.

3 / 3

Total

12

/

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
harness/harness-ai
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.