write-script-ansible

MUST use when writing Ansible playbooks.

Quality

68%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./system_prompts/auto-generated/skills/write-script-ansible/SKILL.md

Quality

Content

78%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 is highly actionable and largely token-efficient, with concrete commands, executable YAML, and a clear intent-based decision flow backed by a metadata validation loop. Its main weakness is structure: with no bundle files and several long inline blocks, progressive disclosure leaves content that could live in separate files in the main SKILL.md.

Suggestions

Move the CLI command glossary and the detailed metadata-sync guidance into a references/ file, leaving SKILL.md a concise overview with signaled one-level-deep links.

Consolidate the edit → generate-metadata → diff/report → preview/test → deploy flow into a single numbered checklist with explicit validation checkpoints.

Surface the cross-references (AGENTS.wmill.md Deploying section, the preview skill) as a short 'See also' list rather than burying them inside paragraphs.

Dimension	Reasoning	Score
Conciseness	The body leads with concrete commands and complete YAML examples and avoids explaining what Ansible or YAML is, with only minor verbosity in the long metadata-sync paragraph and repeated deploy gating that could be tightened.	4 / 5
Actionability	It supplies copy-paste-ready commands (wmill script preview, generate-metadata, generate-metadata rehash with --dry-run and --strict-folder-boundaries), full executable YAML playbook examples, and specific argument-syntax guidance per language, covering the common cases.	5 / 5
Workflow Clarity	Intent-based decision logic (preview vs run vs sync push) and a metadata feedback loop (edit, generate-metadata, diff .lock/.script.yaml, report version bumps, pin) give clear sequencing with checkpoints, but the core edit→metadata→test flow is spread across paragraphs rather than consolidated into one ordered list.	4 / 5
Progressive Disclosure	Sections are well-labeled and there are no deep nested references, but with no bundle files present and over 50 lines, the large inline CLI glossary and metadata paragraph are candidates for split-out reference files and the AGENTS.wmmil.md / preview-skill pointers are buried mid-prose.	3 / 5
	Total	16 / 20 Passed

Description

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

The description is a tight, well-triggered one-liner that clearly scopes itself to Ansible playbook authoring, but it sacrifices specificity by naming only a single generic action and omitting natural synonyms. It is distinguishable and explicitly triggered, just not comprehensive.

Suggestions

Add one or two concrete actions beyond "writing" (e.g., "...author, validate, and run Ansible playbooks as Windmill scripts") to lift specificity.

Include natural synonyms or related terms (YAML playbooks, Ansible automation, roles/inventory) so the trigger matches more user phrasings.

Keep the "MUST use when" trigger but pair it with a brief "what" clause listing the concrete capabilities the skill provides.

Dimension	Reasoning	Score
Specificity	The phrase "writing Ansible playbooks" names a concrete domain but exposes only a single generic action ("writing") with no elaboration of what the skill does within that domain, matching the anchor that names the domain with minimal actions.	2 / 5
Completeness	It states what (writing Ansible playbooks) and when ("MUST use when writing Ansible playbooks") with an explicit trigger clause, but the "what" is thin and could be more specific, placing it just below the fully concrete anchor of 5.	4 / 5
Trigger Term Quality	"writing Ansible playbooks" is a natural phrase users would say and is paired with a strong "MUST use when" trigger, but synonyms and variations (YAML, automation, roles, inventory) are missing, fitting the anchor with some relevant keywords but lacking common variations.	3 / 5
Distinctiveness Conflict Risk	"Ansible playbooks" is a clear, narrow niche unlikely to fire for unrelated skills, with only minor theoretical overlap with a generic YAML or scripting skill.	4 / 5
	Total	13 / 20 Passed

Validation

100%

Warnings & errors only

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: windmill-labs/windmill
Path: system_prompts/auto-generated/skills/write-script-ansible/SKILL.md
Commit: 74af4ed

Reviewed: about 18 hours ago

Table of Contents

Discovery Implementation Validation

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.