CtrlK
BlogDocsLog inGet started
Tessl Logo

schedules

MUST use when configuring schedules.

41

Quality

40%

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

Fix and improve this skill with Tessl

tessl review fix ./system_prompts/auto-generated/skills/schedules/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

57%

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 well-organized, mostly lean reference for Windmill schedules with concrete cron examples and CLI commands plus sensible destructive-operation safety notes. Its main gaps are the missing schedule.yaml file content/schema and the absence of an explicit end-to-end create-and-deploy workflow with a verification step.

Suggestions

Add a minimal {path}.schedule.yaml example showing the actual fields (e.g. cron expression, script/flow path) so the core 'configure a schedule' task is fully actionable.

Frame the workflow as an explicit sequence: create the .schedule.yaml file -> set the 6-field cron expression -> deploy with wmill sync push -> verify with wmill schedule.

Tighten the CLI Commands intro into short bullet points (deploy safety, deploy method, safe-to-run commands) instead of one long compound sentence.

DimensionReasoningScore

Conciseness

The file-naming, cron-format, and command-list sections are lean and earn their tokens, but the CLI Commands intro ('Deploying local changes... can be destructive... only suggest/run a deploy when the user explicitly asks... Deploy via git push or wmill sync push depending on how the repo is wired...') is a dense run-on bundling three distinct points that could be tightened.

2 / 3

Actionability

It gives concrete, executable commands (wmill sync push/pull, wmill schedule) and copy-paste cron examples, but never shows the content/schema of a {path}.schedule.yaml file — the central artifact for the skill's core task of configuring schedules — so guidance is incomplete.

2 / 3

Workflow Clarity

It helpfully flags destructive operations with a preview checkpoint (sync pull --dry-run, deploy-only-when-asked), but it presents reference sections rather than an explicit create-file -> set-cron -> deploy -> verify sequence, and wmill schedule is not framed as a post-deploy verification step.

2 / 3

Progressive Disclosure

At under 50 lines with no bundle files needed, the body is cleanly organized into File Naming, Cron Expression Format, and CLI Commands sections, and defer deploy details one level deep to AGENTS.wll.md — matching the simple-skill anchor for a well-structured overview.

3 / 3

Total

9

/

12

Passed

Description

22%

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 only as an invocation trigger and never states what the skill does, leaving its capabilities unspecified. It uses an imperative second-person form rather than a third-person capability statement. It is distinctive enough to its niche but thin on natural trigger terms.

Suggestions

Add a third-person capability clause stating what the skill does, e.g. 'Creates and deploys Windmill schedule files ({path}.schedule.yaml) with 6-field cron expressions.'

Broaden trigger terms to include natural variations users say: 'cron job', 'recurring run', 'run a flow on a schedule', 'automate a script daily/weekly'.

Combine into one sentence covering both what and when, e.g. 'Creates and deploys Windmill cron schedules. Use when the user wants to schedule a script or flow to run on a cron/recurring basis.'

DimensionReasoningScore

Specificity

The description 'MUST use when configuring schedules.' names a domain but describes zero concrete capabilities of the skill; the imperative 'MUST use' is second-person voice, which the rubric penalizes by reducing specificity, and no actions the skill performs are listed.

1 / 3

Completeness

It gives an explicit 'when' ('when configuring schedules') but entirely omits the 'what' — it never states what the skill does, so it fails the both-what-and-when requirement and matches the missing-'what' anchor.

1 / 3

Trigger Term Quality

'schedules' and 'configuring schedules' are natural terms a user would say, but the description misses common variations users actually use such as 'cron', 'cron job', 'recurring', 'run on a schedule', or 'automate'.

2 / 3

Distinctiveness Conflict Risk

'configuring schedules' points at a recognizable niche, but the single bare word 'schedules' with no capability detail could overlap with generic calendar or task-scheduling skills.

2 / 3

Total

6

/

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
windmill-labs/windmill
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.