Work Avoidance
When to Use This Skill
Work avoidance detects when an operation isn't needed and skips it entirely. Unlike idempotency (which makes reruns safe), work avoidance prevents the run from happening at all.
flowchart LR
subgraph trigger[Trigger]
Event[Event Received]
end
subgraph detect[Detection]
Check{Work Needed?}
end
subgraph action[Action]
Skip[Skip]
Execute[Execute]
end
Event --> Check
Check -->|No| Skip
Check -->|Yes| Execute
%% Ghostty Hardcore Theme
style Event fill:#65d9ef,color:#1b1d1e
style Check fill:#fd971e,color:#1b1d1e
style Skip fill:#5e7175,color:#f8f8f3
style Execute fill:#a7e22e,color:#1b1d1e
When to Apply
Work avoidance is valuable when:
- Distribution workflows push files to many repositories
- Release automation bumps versions without content changes
- Scheduled jobs run regardless of whether work exists
- Monorepo builds trigger on any change but only need subset builds
- API synchronization needs to detect actual drift
- Mutex-locked workflows queue identical operations behind a lock
Implementation
- GitHub Actions: Work Avoidance - CI/CD implementation patterns
- File Distribution - Real-world workflow using these patterns
Techniques
Techniques
Work avoidance uses different techniques depending on what you're checking:
| Technique | Question | Best For | | --------- | -------- | -------- | | Content Hashing | "Is the content different?" | File comparisons, config sync | | Volatile Field Exclusion | "Did anything meaningful change?" | Version bumps, timestamps | | Existence Checks | "Does it already exist?" | Resource creation (PRs, branches) | | Cache-Based Skip | "Is the output already built?" | Build artifacts, dependencies | | Queue Cleanup | "Should queued work execute?" | Mutex-locked workflows |
See Techniques Overview for detailed comparisons and when to use each.
Comparison
Both patterns make automation safe to rerun, but they optimize for different things:
| Concern | Idempotency | Work Avoidance | | ------- | ----------- | -------------- | | Focus | Safe re-execution | Skipping execution | | Question | "Can I run this again safely?" | "Should I run this at all?" | | Resource usage | Uses resources on rerun | Saves resources | | Implementation | Logic inside operation | Logic before operation |
Best practice: Apply work avoidance first, then ensure remaining operations are idempotent.
Anti-Patterns to Avoid
Skip work when the outcome won't change.
Detect Before Execute
Check if work is needed before starting it. Avoid creating PRs for unchanged content, running builds for unchanged code, or processing already-processed items.
Overview
Work avoidance detects when an operation isn't needed and skips it entirely. Unlike idempotency (which makes reruns safe), work avoidance prevents the run from happening at all.
See examples.md for detailed code examples.
Work Avoidance vs Idempotency
Both patterns make automation safe to rerun, but they optimize for different things:
| Concern | Idempotency | Work Avoidance | | ------- | ----------- | -------------- | | Focus | Safe re-execution | Skipping execution | | Question | "Can I run this again safely?" | "Should I run this at all?" | | Resource usage | Uses resources on rerun | Saves resources | | Implementation | Logic inside operation | Logic before operation |
Best practice: Apply work avoidance first, then ensure remaining operations are idempotent.
Techniques
Work avoidance uses different techniques depending on what you're checking:
| Technique | Question | Best For | | --------- | -------- | -------- | | Content Hashing | "Is the content different?" | File comparisons, config sync | | Volatile Field Exclusion | "Did anything meaningful change?" | Version bumps, timestamps | | Existence Checks | "Does it already exist?" | Resource creation (PRs, branches) | | Cache-Based Skip | "Is the output already built?" | Build artifacts, dependencies | | Queue Cleanup | "Should queued work execute?" | Mutex-locked workflows |
See Techniques Overview for detailed comparisons and when to use each.
When to Apply
Work avoidance is valuable when:
- Distribution workflows push files to many repositories
- Release automation bumps versions without content changes
- Scheduled jobs run regardless of whether work exists
- Monorepo builds trigger on any change but only need subset builds
- API synchronization needs to detect actual drift
- Mutex-locked workflows queue identical operations behind a lock
Anti-Patterns
Common mistakes that undermine work avoidance:
- Over-aggressive skipping - Checking existence, not content
- Ignoring error states - Trusting markers without validation
- Stripping too much - Destroying semantic content with broad patterns
- Stale cache keys - Missing inputs that affect output
See Anti-Patterns for details and fixes.
Quick Example
A file distribution workflow that skips version-only changes:
See examples.md for detailed code examples.
This applies Volatile Field Exclusion to avoid creating PRs for version-only changes.
Implementation Examples
- GitHub Actions: Work Avoidance - CI/CD implementation patterns
- File Distribution - Real-world workflow using these patterns
Related
- Idempotency - Making operations safe to repeat
- Graceful Degradation - Fallback when detection fails
- Three-Stage Design - Workflow structure that enables work avoidance
Overview
Work avoidance detects when an operation isn't needed and skips it entirely. Unlike idempotency (which makes reruns safe), work avoidance prevents the run from happening at all.
See examples.md for detailed code examples.
Work Avoidance vs Idempotency
Both patterns make automation safe to rerun, but they optimize for different things:
| Concern | Idempotency | Work Avoidance | | ------- | ----------- | -------------- | | Focus | Safe re-execution | Skipping execution | | Question | "Can I run this again safely?" | "Should I run this at all?" | | Resource usage | Uses resources on rerun | Saves resources | | Implementation | Logic inside operation | Logic before operation |
Best practice: Apply work avoidance first, then ensure remaining operations are idempotent.
Techniques
Work avoidance uses different techniques depending on what you're checking:
| Technique | Question | Best For | | --------- | -------- | -------- | | Content Hashing | "Is the content different?" | File comparisons, config sync | | Volatile Field Exclusion | "Did anything meaningful change?" | Version bumps, timestamps | | Existence Checks | "Does it already exist?" | Resource creation (PRs, branches) | | Cache-Based Skip | "Is the output already built?" | Build artifacts, dependencies | | Queue Cleanup | "Should queued work execute?" | Mutex-locked workflows |
See Techniques Overview for detailed comparisons and when to use each.
When to Apply
Work avoidance is valuable when:
- Distribution workflows push files to many repositories
- Release automation bumps versions without content changes
- Scheduled jobs run regardless of whether work exists
- Monorepo builds trigger on any change but only need subset builds
- API synchronization needs to detect actual drift
- Mutex-locked workflows queue identical operations behind a lock
Anti-Patterns
Common mistakes that undermine work avoidance:
- Over-aggressive skipping - Checking existence, not content
- Ignoring error states - Trusting markers without validation
- Stripping too much - Destroying semantic content with broad patterns
- Stale cache keys - Missing inputs that affect output
See Anti-Patterns for details and fixes.
Quick Example
A file distribution workflow that skips version-only changes:
See examples.md for detailed code examples.
This applies Volatile Field Exclusion to avoid creating PRs for version-only changes.
Implementation Examples
- GitHub Actions: Work Avoidance - CI/CD implementation patterns
- File Distribution - Real-world workflow using these patterns
Related
- Idempotency - Making operations safe to repeat
- Graceful Degradation - Fallback when detection fails
- Three-Stage Design - Workflow structure that enables work avoidance
Examples
See examples.md for code examples.
Related Patterns
- Idempotency
- Graceful Degradation
- Three-Stage Design