slice
Phase 1: Understand the Work
If no feature is specified, open with:
"What are you building? Describe the feature or capability — big or small."
Wait for their answer before proceeding.
Once the feature is known, ask three things — conversationally, not as a form:
"Before we slice this, I need to understand it. Three things:
Who is this for — specifically? Not 'users', but which person, in which moment, with which need.
What does done look like? When this ships, what can that person do that they can't do today?
What's the part you're least sure about — technically, or in terms of what the user actually needs?"
Wait for their answers. Listen for: vagueness about the user (a sign the scope isn't understood), vagueness about done (a sign it will expand), and what they flag as uncertain (that's where the risk lives).
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.
2offboard
Walk through the Designer/Developer wrap-up checklist for offboarding a client engagement — conversationally, one item at a time.
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