Grill before build: the planning interview

Before building a new feature or changing a plan, interview the user until you both share one understanding of what will be done. Treat this as the default step, not an extra; only an explicit "skip it" from the user turns it off.

When

• Every new feature, improvement or change of direction.
• Not needed: purely informational questions, and trivial edits where the user said exactly what to do and there are no real options.

Before the first question

• Do your homework. Facts (what exists in the code, how something works, what was decided before, whether someone is already doing it) you look up yourself: the codebase, the docs, the decision log, open issues. Grilling someone about a feature that already shipped wastes their time.
• Map the decision tree: which decisions depend on which. Resolve parents first.

Rules

1. One question at a time. Several questions at once get half-answered. Wait for the answer before asking the next one.
2. Every question carries your recommended answer, first and marked as recommended, with 2-4 concrete options and room for a free answer. A question without a recommendation pushes your work onto the user.
3. Ask for decisions, never for facts. If a fact can be found by looking, look.
4. Walk every branch of the tree: scope, who uses it, edge cases, what is out of scope, how success is checked, what it costs, what is irreversible.
5. Name defaults as decisions. What is on by default, who gets notified, what survives deletion: a default is a decision nobody made until you ask.
6. Do not hide alternatives because you think they will not be needed. Show them, recommended first.
7. Do not reopen what was decided without a new fact; say what the new fact is.
8. No action until the user confirms that shared understanding is reached.

How to write a question

• It stands alone: one line of context, then the question.
• Options are short enough to fit on a button, recommended option first.

• Example:

  Deleting an account currently keeps its orders for reporting. What happens to a deleted user's orders?

  1. (Recommended) Keep them, anonymise the customer name and email
  2. Delete them with the account
  3. Keep them unchanged
  4. Something else

• In a team, one lead collects the questions from everyone working on the task, removes duplicates and orders them by how much they block the work before anything reaches the user.

After: hand off the decisions

Write a short summary of the decisions: what was decided, the date, who decided, and what is explicitly out of scope. Save it where the next person or session will find it (the design doc, the issue, the team's decision log), so the next task does not grill the same ground. The summary should let someone with no access to this conversation start the work.

Adapted from the grill-me and handoff skills in mattpocock/skills (MIT licence, copyright Matt Pocock). See NOTICE.md.