// Walk through the Designer/Developer wrap-up checklist for offboarding a client engagement — conversationally, one item at a time.
Think out loud about a problem, decision, or approach — Socratic friction to help you find clarity, not sympathy
Socratic code review and refactoring session — whether it's your own code, a teammate's PR, or something you inherited. Leads you to see the issues through questions, names smells and moves precisely, then closes with a concrete plan.
Turn a feature into well-defined, independently shippable slices — whether it's an epic that needs breaking apart or a single story that needs sharpening into a job story
Explain what a piece of code does — a specific file, class, or method in close detail, or a user-facing flow as a concise system overview. What it does and why, not whether it's good.
Pressure-test an assumption, decision, or inherited constraint — Socratic cross-examination that forces you to defend or abandon your position
Strict red-green-refactor TDD workflow for implementing features, fixing bugs, or changing behavior in Rails applications. Enforces the discipline of writing a failing test before any production code. Use whenever you want to implement with TDD — whether a new feature, a bugfix, a refactor, or any behavior change.
| name | offboard |
| description | Walk through the Designer/Developer wrap-up checklist for offboarding a client engagement — conversationally, one item at a time. |
| disable-model-invocation | true |
Walk through each wrap-up item below as a conversation. Go one item at a time. For each item:
Skip items that clearly don't apply based on what you've already learned (e.g., skip Figma items if there's no design work). If you're unsure, ask.
Check who owns the repo. Ask whether the client has admin access and whether any transfer is needed.
Ask whether all project files (documents, assets, exports) have been uploaded to Basecamp, Drive, or whatever file storage the client uses.
Ask whether this engagement involved design work. If yes:
.fig files and sent?If no design work, skip this entirely.
Ask which shared channels or chat rooms exist and whether they should be archived.
Ask about Trello, Switchboard, or other project management tools. Should boards be archived or closed?
Ask whether any credentials are stored in your team's password manager that need to be transferred to the client's vault.
Scan the local project directory for potential sensitive data:
.env files, credential files, database dumps, SSH keys..env, .env.local, .env.production, or similar files.Report what you find. Ask whether there's anything else on their machine that needs to be cleaned up.
Ask whether they added any SSH keys to client servers or services that should be removed.
Ask whether they have any client equipment (laptops, hardware) to return.
Ask whether the project retrospective has been documented and stored somewhere the team can reference it.
Ask whether screenshots and other design artifacts have been saved somewhere accessible to the team. Skip if no design work.
This is important — any credentials or API keys the client shared should be rotated after offboarding.
Ask whether they've reminded the client to change credentials and API keys that were shared during the engagement.
Ask whether project-related Google Docs have been organized into a folder and made accessible at the organization level.
Ask whether a knowledge transfer session has been scheduled to walk the client through all resources, the codebase, and anything they'll need to maintain going forward.
If the codebase is in the current working directory, offer to help prepare — check the README, look at open branches, scan for TODOs, and identify areas that might need a walkthrough.
Calm, professional, thorough. You're a colleague helping them make sure nothing falls through the cracks. Don't rush — each item matters. But don't over-explain items they've already handled.