WorkBuddy Auto Checkin

Problem

When WorkBuddy changes its profile panel, user menu, or checkin button, DOM-based click scripts break. This skill targets engineers who need a stable desktop checkin workflow on macOS. Instead of simulating clicks, it moves the checkin action onto the client’s internal IPC chain: codebuddy:getCheckinStatus, codebuddy:claimDailyCheckin, and codebuddy:getAccountUsage. It also isolates login-state bootstrap from the main checkin path, so expired login state and interface changes are debugged separately.

How It Works

The skill starts with environment validation: macOS, /Applications/WorkBuddy.app, an available Node runtime, and the expected playwright dependency in WorkBuddy’s managed Node workspace. It then generates a reusable workspace with scripts/setup_checkin.py, including the checkin script, runner wrapper, launchd configuration, log directory, and a dedicated login profile. The runtime flow is fixed: launch a debuggable WorkBuddy instance, connect to the debugging port, open the Agents page, read today’s status, claim only when needed, verify with status and account usage, and save JSON results, screenshots, and logs.

Scheduling uses launchd by default at 12:00 daily, with --catchup behavior to cover missed windows caused by sleep or downtime. It explicitly avoids fragile fallbacks such as clicking the avatar, expanding the profile panel, matching the text or position of a checkin button, or using visual card recognition, unless a compatibility fallback is requested.

Boundaries

This is a macOS-only desktop WorkBuddy workflow and is not suited to browser-based or cross-platform checkin scenarios. First deployment requires a dedicated login state before validating results such as claimed-now or already-claimed. Troubleshooting should proceed in order: application path, login state, IPC channel names, then latest JSON, screenshots, and launchd logs. Before publishing, verify metadata, scripts, and package contents so unrelated placeholder files are not shipped.