offboard

name	offboard
description	Plan and work through project, client, vendor, or team offboarding. Use for handovers, access removal, ownership transfer, documentation, credential rotation, data cleanup, and knowledge-transfer checklists.

Offboard an Engagement

Build a checklist that fits the actual engagement. Inspect available context and ask about missing systems, owners, deadlines, regulatory obligations, and the destination team before proposing actions.

Areas to Cover

• source repositories, branches, releases, and code ownership;
• architecture notes, runbooks, setup instructions, and known risks;
• infrastructure, domains, stores, devices, and third-party services;
• chat, email, project-management, design, and document systems;
• password-manager entries, API keys, SSH keys, service accounts, and tokens;
• client or production data retained on personal or company devices;
• unfinished work, open incidents, support obligations, and named owners;
• knowledge-transfer sessions and recorded decisions; and
• credential rotation and verification after access changes.

For each item, record owner, target date, status, evidence, and blocker. Separate what can be inspected read-only from actions that change access, ownership, or data.

Safety

Never delete data, revoke access, rotate credentials, transfer ownership, archive communication, or contact another person without explicit confirmation for that action. Show the exact target and consequence before irreversible or externally visible steps. Preserve an audit trail required by the organization.

Finish with unresolved risks, remaining owners, and the next concrete handover action. Do not generate a separate document unless the user asks for one.

Provenance

Adapted from Thoughtbot's rails-consultant offboard skill at revision f2cb97d. Distributed under the accompanying MIT license.