# Offboarding Checklist > Employee offboarding runbook for {{projectName}}. Detects newly marked departures via the {{hris_group}} group in Okta, then works one independent case per departure across Okta, Google Workspace, Google Drive, and GitHub — revoking access, transferring ownership, and reclaiming licenses — holding the ownership transfer for a human approval gate (never deleting an account) and posting the completed checklist to {{notify_channel}}. - Skill: `kortix-ai/offboarding-checklist` (Agent Skill) - Install (CLI): `npx skillmds@latest add kortix-ai/offboarding-checklist` - Raw SKILL.md: https://api.skillmd.com/api/skills/kortix-ai/offboarding-checklist/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: kortix-ai (https://skillmd.com/u/kortix-ai) - Updated: 2026-09-10 - Page: https://skillmd.com/skills/kortix-ai/offboarding-checklist --- Run the full offboarding checklist for each employee departure, in the right order, without skipping the steps that are easy to forget under time pressure. Each run is a fresh session on a schedule, and a single run can find more than one new departure — handle each one as its own independent case, and a failure or a pending approval on one case must never block the others. Nothing carries over between runs. Reversible steps (revoking access, reclaiming licenses) run immediately; transferring ownership away from a person is irreversible and waits for a human. Account deletion is never performed by this agent — it is out of scope entirely. - The scheduled check fires and needs to look for new departures. - A human asks the agent to offboard a specific person out of band. - A prior offboarding case has items still pending a human approval and needs a status check. ## Step 0 — Detect the departure Check the `{{hris_group}}` group (or equivalent departure flag) in Okta for anyone newly added since the last check: - Pull current membership of `{{hris_group}}`. - Diff against who was already processed — look on the person's Okta profile for a prior `offboarding: complete` or `offboarding: pending-approval` note left by an earlier run. - Treat each newly marked person as one independent case. Nothing else in this step touches state from a previous run — this session doesn't have one. A failure or a pending approval on one case must never block working the others found in the same run. If nobody new is marked, end the turn; there is nothing to run. ## Step 1 — Open the case For the departing person, record: full name, email, Okta user ID, GitHub username (if known), and the manager's Google Workspace email — the intended new owner for the document and shared-drive ownership transfer in Step 3. This is the scope of everything that follows — don't touch access for anyone else. ## Step 2 — Okta: revoke SSO and app access - Deactivate the person's Okta account. This is reversible — a deactivated user can be reactivated. Account deletion is never performed here or anywhere in this workflow. - Pull the app assignments hanging off the account and remove them, so downstream SSO-brokered access (including Slack, where it's SSO-connected) drops with it. Release any per-user paid license tied to those app assignments. - Record which apps were deprovisioned in the checklist. ## Step 3 — Google Drive and Workspace: transfer ownership, then suspend - Using Google Drive, list the documents and shared drives the person owns. - Reassign ownership to the manager's Workspace email recorded in Step 1 so nothing is orphaned. **This is irreversible — hold it at the approval gate (Step 5) before executing**, and note the intended new owner in the checklist so the approver can confirm it's right. - Once the ownership transfer is approved and done, suspend the person's Google Workspace account via the admin console (reversible) and release its license back to the pool. ## Step 4 — GitHub: remove org and team access - Remove the person from the GitHub org and every team they're a member of. - If they're the sole owner of a repository or the last admin on a team, flag it instead of removing them outright — that needs a human to name a new owner first. - Reclaim any paid GitHub seat. ## Step 5 — Approval gate for the ownership transfer Before the ownership transfer in Step 3 executes, stop and surface it as a pending approval in the checklist: what it is, why it's needed, and the intended new owner. Only proceed with the transfer once a human approves. Account deletion is never attempted by this agent — deactivation/suspension is the terminal state it can reach; if an account genuinely needs to be deleted, that decision and action belong to a human outside this workflow. ## Step 6 — Post the completed checklist Post to `{{notify_channel}}`: every step taken (system, action, result), every item still waiting on human approval with why, and anything that failed with the error. Never report a step as done unless it actually completed — a pending approval is listed as pending, not as done. - **Human approval gate for ownership transfer.** Reassigning document or shared-drive ownership away from a person always stops for a human. No exceptions, no "obviously fine" fast path. - **Never delete, only deactivate/suspend.** Account deletion is out of scope for this agent entirely — it is never performed, approval-gated or otherwise. Deactivation/suspension is the terminal state the agent can reach; an actual deletion is a human decision made outside this workflow. - **Scoped, brokered credentials.** Okta, Google Workspace, Google Drive, and GitHub access is injected into the sandbox at runtime, scoped to this agent's grant. - **Independent cases, no cross-run memory.** Each run is independent and can contain more than one departure — don't infer anything about today's departures from a previous session's state beyond what's recorded on each person's own profile/notes, and never let one case's failure or pending approval block another. - **Isolation.** Every departure case runs inside the same scoped sandbox for that run; only the checklist result leaves it.