The problem: a headless LaunchAgent keepalive is the right tool when nobody’s watching, it spawns a fresh claude -p elsewhere and reports back once it’s done. It’s the wrong tool when you’re actively in the chat and want the conversation itself to pick back up here, in front of you, the moment a usage cap clears. Building a background lane when what you actually asked for was the chat to resume is the mistake this skill exists to prevent.
qq-cap-resume keeps the resume inside the same session using ScheduleWakeup: confirm the interruption is really a cap and not a genuine error, schedule a wakeup with a specific resume prompt instead of a generic status check, and on wakeup either continue the real work if the cap cleared or reschedule again if it hasn’t, up to however many hops the cap window needs. Every hop lands as a visible turn in the same thread, so you can see the session is alive and waiting instead of wondering if it died.
Known failure mode, confirmed live: a wakeup that fires while still capped can’t produce any output at all, including the “still capped, rescheduling” message, which means it also can’t schedule the next retry. The chain just stops with nothing announcing it. The fix is to pair in-chat ScheduleWakeup with a separate, dumb, outside-the-session timer (a LaunchAgent-style ping) that doesn’t depend on this session successfully producing output, specifically to guarantee some retry eventually fires even if one self-chained hop dies mid-cap. Neither mechanism alone is fully robust; together they are.
Part of Operator Skills, a collection of skills for running a real Claude Code setup.