schedules

MUST use when configuring schedules.

Quality

63%

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/schedules/SKILL.md

Quality

Content

72%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 a lean, well-organized reference that delivers genuinely non-obvious Windmill specifics (6-field cron, schedule file naming, deploy safety semantics) without padding. Its main weaknesses are the missing schedule-file YAML example, which limits full actionability, and the lack of a validation step before the destructive sync push. Structure and token efficiency are strong.

Suggestions

Add one complete example .schedule.yaml file (script path, arguments, and cron schedule fields) so a schedule can be authored from the skill alone.

Add a verification step before destructive deploys — e.g. preview with `wmill sync push --dry-run` (if supported) or list schedules after push to confirm the new schedule landed.

Replace the multi-line ASCII cron diagram with a compact one-line field summary to trim the most token-heavy section.

Dimension	Reasoning	Score
Conciseness	The body is efficient: the intro line, 6-field cron diagram, common examples, and CLI commands each convey non-obvious Windmill-specific facts (seconds field, path-derived naming, deploy semantics). The ASCII cron diagram could be compressed to a one-line field summary, which is a minor instance of over-explanation — anchor 4, not anchor 5.	4 / 5
Actionability	Concrete file-naming pattern with a real example, five executable cron expressions covering common cases, and real CLI commands — mostly copy-paste ready. The gap is that no example of the actual .schedule.yaml file contents (script path, arguments, schedule fields) is shown, so a user could not fully create a schedule file from this alone — anchor 4's 'minor gaps', not anchor 5.	4 / 5
Workflow Clarity	The skill involves destructive operations (the body itself calls sync push "destructive to remote state" and notes sync pull overwrites local files). There is a safety gate (only push on explicit request) and a preview flag for pull, but no validation before push and no create→deploy→verify sequence — the destructive-operations cap of 3 applies. Not anchor 2, since precautions and sequencing hints are genuinely present.	3 / 5
Progressive Disclosure	The skill is under 50 lines, has no bundle files, and is organized into clear well-titled sections (File Naming, Cron Expression Format, CLI Commands) with one clearly signaled external reference (AGENTS.wmill.md). This matches the simple-skill exception for a top score.	5 / 5
	Total	16 / 20 Passed

Description

36%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 functions purely as a trigger and omits any statement of what the skill actually does, costing it completeness and specificity. It does provide an explicit, imperative use-when clause with one natural trigger term. Expanding it to state the concrete capabilities (creating Windmill schedule files with 6-field cron expressions, deploying via wmill sync) would fix both problems at once.

Suggestions

Add a 'what' clause stating the concrete capabilities, e.g. "Create and manage Windmill schedules: write {path}.schedule.yaml files with 6-field cron expressions, list them, and deploy via wmill sync push. Use when configuring schedules, cron jobs, or recurring automated runs."

Include natural trigger variations users would actually say — "cron", "recurring", "automate", "run automatically" — alongside "schedules".

Mention Windmill in the description to reduce conflict risk with generic calendar-scheduling or cron skills.

Dimension	Reasoning	Score
Specificity	The description "MUST use when configuring schedules" names the domain (schedules) but states no actions the skill performs — there is no 'what' content at all, only a trigger clause. It sits between anchor 1 (entirely vague) and anchor 3 (1-2 concrete actions), closer to anchor 2 because a domain is explicitly named.	2 / 5
Completeness	Only the 'when' is present ("MUST use when configuring schedules") with no 'what' — exactly anchor 2's second disjunct. It cannot be anchor 3, which requires a clear 'what', nor anchor 4, which requires both.	2 / 5
Trigger Term Quality	"schedules" and "configuring" are natural terms users would say, but common variations like "cron", "recurring", "automate", or "run regularly" are missing. This matches anchor 3 (some relevant keywords, missing common variations) rather than anchor 4, which requires only a few missing terms.	3 / 5
Distinctiveness Conflict Risk	"Schedules" is a common word that could also refer to calendar/meeting scheduling or generic cron tooling, and the description never mentions Windmill, so overlap with similar skills is plausible — anchor 3. Not anchor 2, since the trigger is narrower than 'document files'-level breadth.	3 / 5
	Total	10 / 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/schedules/SKILL.md
Commit: af42c47

Reviewed: 8 days 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.