scheduled-workflows

name	scheduled-workflows
description	Design and maintain reusable scheduled workflows that produce durable artifacts, notify only when useful, and expose failures clearly. Use when building cron-driven reports, digests, recurring checks, background summaries, change-detection jobs, or any automation that should run repeatedly without becoming noisy or disposable.

Scheduled Workflows

Turn recurring tasks into durable background workflows, not one-off reminders.

Core rule

Prefer artifact-first automation: create a durable output, then notify only when the result, delta, or failure is worth surfacing.

Workflow template

Define each scheduled workflow with these parts:

1. Trigger — when it runs
2. Inputs — which sources it reads
3. Process — how it transforms inputs
4. Outputs — which files or records it writes
5. Delivery — when and where to notify
6. Failure — how errors are surfaced or retried

Default operating pattern

Use this sequence:

1. collect input
2. analyze or transform
3. write a durable artifact
4. compare against prior state when useful
5. send only the necessary notification
6. expose failures clearly

Strong defaults

• Prefer files over ephemeral chat-only output.
• Prefer change summaries over full repeated dumps.
• Prefer low-noise delivery.
• Prefer visible failure reporting over silent breakage.

Artifact patterns

Use durable artifacts such as:

• daily briefings
• weekly reviews
• mail digests
• agenda summaries
• competitor watch logs
• healthcheck reports
• change-detection snapshots

Name outputs consistently, keep retention deliberate, and make artifacts easy to audit later.

Delivery policy

Choose delivery behavior deliberately:

• artifact only: store results without notifying
• notify on change: alert only when new or changed information appears
• notify on failure: alert when the workflow breaks or inputs are missing
• always notify: use only for high-value summaries that are expected every run

Do not default to noisy every-run notifications. Prefer the quietest mode that still preserves user value.

Failure handling

When a workflow fails or degrades:

1. preserve enough evidence to debug
2. state which stage failed
3. say whether retry is safe
4. distinguish success, partial-success, degraded, and failed states
5. avoid pretending the run succeeded

Hard constraints

• Do not design scheduled jobs that only send messages and leave no durable artifact unless the task is intentionally ephemeral.
• Do not send repetitive full-output notifications when a delta or short summary is enough.
• Do not hide failures.
• Do not label degraded or partial runs as full success.
• Do not let a schedule imply permission for unrelated side effects.

Outputs

When defining or reviewing a scheduled workflow, produce:

• trigger
• inputs
• process summary
• artifact location
• delivery mode
• failure behavior
• delta policy
• chosen channel strategy, if notifications are used

References

Read these references as needed:

• references/workflow-patterns.md for reusable background automation patterns and notification strategies
• references/artifact-naming-and-retention.md for output naming, retention, and delta-companion patterns
• references/common-workflow-examples.md for concrete recurring workflow examples
• references/failure-retry-and-degradation.md for failure classes, retry policy, degraded modes, and run-state reporting
• references/delivery-strategies.md for delivery-mode choice, channel routing, noise controls, and cron-announce vs explicit-message guidance