refresh-cycle-planninglisted

# Refresh Cycle Planning ## Overview Most MSPs discover a hardware refresh need reactively: a device fails, or a client gets stuck on an OS that just hit end-of-support with no migration path, and the replacement conversation happens under time pressure with no budget lead time. This skill exists to move that conversation earlier — by combining three signals that are each individually useful but collectively much stronger — into a forward-looking calendar the account team can use in a quarterly business review or a capital-planning conversation, well before any of the underlying risk becomes urgent. The three input signals, each covered by a sibling skill: 1. **Warranty expiration** (`warranty-tracking`) — when hardware coverage lapses. 2. **EOL/EOS timing** (`eol-eos-flagging`) — when the OS or hardware itself stops being supported. 3. **Device age** — how long the device has been in service, pulled from RMM first-seen/enrollment date or purchase date where available. No single signal is sufficient on its own. A device can be young with an expired warranty (a warranty that was never worth much to begin with on a low-end model), old but still fully supported and under an extended warranty, or mid-life but running an OS that's about to lose support regardless of hardware condition. This skill's job is to weigh all three together into one defensible tier per device, not to rank on whichever signal happens to be loudest. This is not a procurement or quoting skill