OpenParable
Skip to content
← Back to skills

Offboarding Checklist

DevOps & Security
offboarding-checklist

Offboarding Checklist is an Agent Skill for devops & security published in the kortix-ai/suna repository on GitHub: a SKILL.md instruction file an AI agent can load to do this task.

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}}.

View on GitHub ↗
QUICK START

How to use this skill

Bring this guide into your coding agent with a prompt tailored to the tool you use.

  1. Open your project in Codex.
  2. Copy and paste the prompt below.
  3. Review files and risks before approving any action.
Prompt to paste
Inspect the Agent Skill at https://github.com/kortix-ai/suna/blob/HEAD/packages/starter/templates/marketplace/runtime/skills/offboarding-checklist/SKILL.md and all supporting files. Report provenance, permissions, scripts, dependencies, and security risks. Propose an exact installation into .agents/skills/offboarding-checklist, but wait for my approval before writing files or running scripts.

Copying this prompt does not install or run the skill. Review third-party files before use.

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.