offboard
Behavior
Walk through each wrap-up item below as a conversation. Go one item at a time. For each item:
- Explain what needs to happen and why.
- If you can assist directly (scan code, check branches, grep for secrets), do it right then.
- Ask whether the item applies, whether it's done, or whether they need help.
- Move on when they confirm.
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.
Checklist
1. Transfer codebase ownership to the client
Check who owns the repo. Ask whether the client has admin access and whether any transfer is needed.
More from thoughtbot/rails-consultant
explain
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.
2slice
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
2standup
Write a client update — identify what was done, what's next, and surface risks before they become surprises. End of day, start of day, or end of week.
2socratic-review
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.
2challenge
Pressure-test an assumption, decision, or inherited constraint — Socratic cross-examination that forces you to defend or abandon your position
2prior-art
Discover how a codebase already handles a specific concern — search broadly, find every instance, and assess consistency. The "how does this app do X?" tool.
2