Skill Detail

Run durable .NET agent schedules with Quartz.NET

Use Quartz.NET to schedule recurring, delayed, or cron-triggered .NET agent jobs with persistent triggers, hosted-service integration, and reviewable job definitions.

Templates & WorkflowsMulti-Framework
Templates & Workflows Multi-Framework Security Reviewed
⭐ 7.1k GitHub stars
COPY SKILL INSTRUCTIONS (OPTIONAL)
npx skills add agentskillexchange/skills --skill run-durable-dotnet-agent-schedules-with-quartznet Copy
Uses the third-party skills CLI, not an ASE-owned installer. Check your agent’s compatibility. This copies instructions; complete the upstream tool setup below separately.
At a glance
Tools required
.NET SDK/runtime and the Quartz NuGet package
Install & setup
Install the package with dotnet add package Quartz, define Quartz jobs and triggers in the .NET service, and wire the scheduler into the hosted application using the upstream quick-start documentation.
Author
quartznet
Publisher
Organization
Last updated
Sep 19, 2026
Quick brief

Use Quartz.NET when an operator needs a .NET service or agent runtime to run recurring evaluations, refresh jobs, reports, maintenance tasks, or delayed automations on a durable schedule. Invoke it instead of using an external product dashboard or ad hoc timers when the schedule should live in application code, use cron-like triggers, integrate with .NET hosting, and be reviewed alongside the agent service. The scope boundary is scheduling and executing .NET jobs with Quartz triggers and stores; it is not a generic automation platform, queue, or full observability product.

How it works

What this skill actually does

Inputs and prerequisites: .NET SDK/runtime and the Quartz NuGet package.

Setup notes: Install the package with dotnet add package Quartz , define Quartz jobs and triggers in the .NET service, and wire the scheduler into the hosted application using the upstream quick-start documentation.

Source and verification boundary: use https://www.quartz-scheduler.net/ as the canonical reference before running the workflow; keep commands, API calls, CLI usage, and generated outputs reviewable against that upstream source.

Framework fit: publish this as a Multi-Framework workflow only when the operator can invoke the documented toolchain directly, rather than treating the upstream project as a generic product listing.