What problem does it solve? Smart contract automation often fails through non-deterministic upkeep checks, duplicate executions that corrupt state, or reliance on off-chain data. This Skill provides a canonical pattern for building keeper automation that is read-only, idempotent, and safe to retry. ## Core Features & Use Cases - Deterministic checkUpkeep: Enforces read-only checks based solely on on-chain state and stored timestamps, never external systems or mempool data. - Idempotent performUpkeep: Re-validates preconditions before executing one encoded action per call, with deterministic revert reasons like NOT_NEEDED or ALREADY_REQUESTED. - Manual fallback: Keeps public functions available so protocol progress never depends on keeper availability. - Use Case: When building a lottery or phased protocol that needs automated phase advancement, VRF draw requests, and scheduled day open/close logic, apply this pattern to ensure repeated keeper calls never double-request draws or corrupt day state. ## Quick Start Use the automation-upkeep skill to implement checkUpkeep and performUpkeep for my contract's phase transitions with idempotent retries and manual fallback functions.