Offboard employee
Skill bonusly/bonusly-claude-plugin/skills/offboard-employee
Bonusly's Claude Plugin
npx -y skills add bonusly/bonusly-claude-plugin --skill offboard-employeeAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when an employee is leaving the company, deactivating or archiving a user, removing someone from Bonusly, or reactivating a previously deactivated account.
SKILL.md
2.9 KB, as published. Nobody here has run it
Offboarding an employee means deactivating their Bonusly account safely — and, if they manage people, deciding what happens to their direct reports first. This skill also handles reactivating someone who was deactivated by mistake or who has returned.
Start by resolving the person. Use searchUsers or getUser to find them by name or email, then adminGetUser to load their full admin profile. Present a clear summary — name, email, department, manager, role — so the admin can confirm this is the right person before anything happens.
Check for direct reports before deactivating. Call getDirectReports for the user. If they manage people:
- List the reports and tell the admin these people will be left without a manager.
- Ask whether to reassign the reports to a new manager (resolve the new manager by name or email, then call
adminUpdateUserfor each report with the newmanager_email) or to clear their manager (adminUpdateUserwithclear_manager). - Do this before deactivating the departing user.
Never deactivate without explicit confirmation. After showing the profile and resolving any direct reports, ask the admin to explicitly confirm — e.g. "Yes, deactivate [name]." Do not call adminDeactivateUser until they say so in plain terms. Only then call adminDeactivateUser with the user's ID. Deactivation is scheduled in the background, so tell the admin it may take a moment to take effect.
Some users cannot be deactivated: the last remaining company admin, and integration-protected users when manual management is disabled. If adminDeactivateUser fails for one of these reasons, surface the error message plainly rather than retrying.
Reactivation branch. If the admin instead wants to bring someone back, resolve the deactivated profile, confirm it's the right person, and — only after they explicitly say to proceed — call adminActivateUser with the user's ID. Activation is also scheduled in the background. Afterward, offer to fix the manager, department, or role with adminUpdateUser, and to send a welcome-back recognition (see the onboard-new-hire skill for the recognition flow).
Finish with a summary of what was done: reports reassigned (if any), account deactivated or reactivated, and any follow-ups still needed.
If a write call (adminDeactivateUser, adminActivateUser, adminUpdateUser) reports an error, don't blindly retry. Because deactivation and activation run in the background, an error can come back even though the change was already scheduled or applied. First re-fetch the profile with adminGetUser to check the current state, and only retry if the change genuinely didn't take.
Access note: these actions require user:administer. If a call fails on permissions, surface the required scope.