Interview the user
The problem
Section titled “The problem”You hand the agent a task, it runs for a while, and what comes back isn’t what you had in mind. Maybe it refactored the wrong layer, picked a design you’d already ruled out, or solved a narrower problem than the one you have. The work isn’t wrong so much as it’s answering a question you didn’t ask.
Why it happens
Section titled “Why it happens”Agents are trained to finish tasks. When your request leaves something open — and a real task always does — the agent fills the gap with the most likely interpretation and keeps moving. Those guesses are invisible. You only find out which ones it made when you read the diff.
Most harnesses offer a plan mode to catch this earlier, and it helps. But a plan is the agent’s best guess written down. It still resolves the open questions on its own; it just shows you the result. At the points that matter most — the architectural pivots where one choice rules out several others — a plan that guessed wrong reads as confidently as one that guessed right, so it’s easy to approve and only notice the bad assumption later.
The fix: make it ask first
Section titled “The fix: make it ask first”Get the agent to interview you before it writes anything. Instead of guessing at each decision point, it asks you, one question at a time, and waits for your answer before moving to the next. The assumptions surface as questions while they’re still cheap to change, rather than as code you have to unpick.
The /grill-me skill runs this loop for you — it’s one of the
team skills that ship in the agent config repo. It walks the
decision tree one branch at a time, and at each step it does two things that make
the interview worth your time:
- It explores the codebase instead of asking what it could find out. Questions it can answer by reading your code, it answers by reading your code. Your attention goes to the genuine decisions, not to facts the agent could look up.
- It proposes an answer to every question, with reasoning. You’re reacting to a concrete recommendation, not generating an answer from a blank page. That’s faster, and it surfaces options you might not have considered — the interview becomes a design conversation, not an interrogation.
By the end you have a shared understanding written down, and the agent is far less likely to wander off once it starts building.
What it looks like
Section titled “What it looks like”Here’s the start of a real session: refactoring the licensing layer of a WinForms app. The developer asked the agent to interview them about the plan before writing anything. Notice that the agent reads the relevant code first, summarizes what it found, and only then asks its first question — with a recommendation attached.
I want to refactor ClsLicenseManager and CloudLicenseSession. The manager
has too many responsibilities and tracks a tangle of state, and the split
between it and the session wrapper is clunky and error-prone. We also need to
be robust when the machine is offline.
Interview me relentlessly about every aspect of the plan, one question at a time, until we reach a shared understanding. For each question, recommend an answer. If a question can be answered by exploring the codebase, explore it instead of asking.
Before I ask anything, let me get a picture of what’s there.
ls Alastri.Hub.Program/Service/Service/ClsLicenseManager.csCloudLicense/CloudLicenseSession.csIClsLicenseManagerWhat I see: ClsLicenseManager (~1200 lines) handles license listing,
session lifecycle, per-process tracking, the refresh loop, auth re-acquisition,
and persistence — all under one lock. CloudLicenseSession wraps the upstream
licensing library but mirrors per-session state the manager also holds, so the
two are poked from many sites. There’s also a parallel legacy LicenseManager
that callers branch to based on auth mode.
Question 1 — Scope of the refactor
The plan targets the CLS path, but the legacy LicenseManager shares the same
call sites through useCls ? ... : ... branching. Which is in scope?
- (a) CLS only — leave the legacy path alone, keep the branching.
- (b) CLS first, but design the new interfaces so the legacy path could slot behind them later.
- (c) Both at once — unify them under one interface now.
My recommendation: (b). The duplicated branching is a symptom of the same
smell you’re feeling in ClsLicenseManager, so it’s worth designing with the
legacy backend in mind. But porting it now (c) inflates the scope a lot — its
refresh and expiry semantics don’t map cleanly onto the CLS path. Which matches
your intent?
The legacy LicenseManager is on the deprecation path but won’t go away for a
long time, and it’s not going to change. Prioritize the CLS side only — so (a).
Got it — (a), scoped to CLS only, branching stays as-is. I won’t design speculatively around the legacy path.
Question 2 — Shape of the deliverable
You mentioned “a markdown file in the project.” What is that file, exactly?
- (a) An architecture doc — describes the target end-state. Lives long-term.
- (b) A refactor plan — an ordered sequence of shippable steps. Tactical; deleted once executed.
- (c) Both — a short target-architecture section, then a migration plan that references it.
My recommendation: (c). Your pains are structural, so you need a target picture to aim at — but the code is live and load-bearing, so you also need an incremental path that keeps the WCF surface stable at each step. The target section anchors the why of each migration step.
The pattern repeats: explore, summarize, ask one question with a recommendation, wait. Each answer narrows the next question, so by the time the agent writes the plan, the decisions are yours and the agent’s understanding matches your intent.