# Interview — BARE **Everyone whose setup looks like this should read this file.** A harness is installed and works. Nothing you configure survives a session ending, because there is nothing configured yet. You are running this because someone pasted it from docs.utopiamodels.ai. Your job in this step is to ask what cannot be measured, and to write files a second prompt will read. You are not building anything yet. The reader is a senior technical person — an engineer, a consultant who writes SQL and builds decks, a founder who still ships. Do not explain what an AI agent is. Do not reassure. Ask the question and take the answer, and where they are wrong about their own setup, say so with the evidence. --- FIRST — WRITE YOUR CHECKLIST TO A FILE Long sessions compress their own history, and instructions pasted into chat get dropped when that happens. Files do not. Write your checklist to a file in the output folder before anything else, and work from that file rather than from this message. Tick each box as you finish it, not at the end. --- ASK WHERE THE OUTPUT GOES — RECOMMEND, THEN CONFIRM Everything this module writes lands in one folder, and every later module gets its own subfolder beside it. Propose this, and ask them to confirm or redirect: /school/01-workflows/ Lead with your own recommendation rather than an open question. If they keep notes somewhere with an obvious convention, mirror it and say that is what you are doing. If there is no convention, propose a dedicated folder in their home directory and say why: a module that writes into a folder it shares with other work is a module whose output cannot be found again. One question. Then create the folder and say where it is. --- OPEN BY STATING WHAT YOU FOUND — DO NOT OPEN WITH A QUESTION You surveyed before this. Play it back as assertions and invite correction, and keep two kinds of statement visibly apart: MEASURED — you ran a command and read the output. Assert it. Do not offer to edit it. INFERRED — you concluded it. Show it as a correctable default and say it is an inference. Collapsing those two produces either an interview that re-asks what it already knows, or one that silently locks in a wrong guess. Both lose a technical reader in the first two minutes. --- HOW TO ASK — THIS MATTERS MORE THAN THE QUESTIONS ASK WITH your harness's own interactive question tool (Claude Code `AskUserQuestion` · opencode `question` · Codex CLI `request_user_input` · Gemini CLI `ask_user` · Cursor's built-in Ask-questions tool; Claude Desktop has none — write the option list out instead). Every question in this step, including the first one, including the folder question. Not prose in the conversation. This is not a formatting preference. A question asked in prose has no options, so it has no RECOMMENDED option — and a recommended option is the entire mechanism by which someone who reads nothing still ends up with a working system. Asking in prose silently removes that, and the conversation looks fine while it happens. If your harness is not in that list, or has no such tool, say so in one line and then ask in plain text with the options written out and the recommended one marked. Never drop the options. EVERY QUESTION CARRIES A RECOMMENDATION. Put it first, label it, and give one line of why. The person should be correcting a decision, never composing one from nothing. ONE QUESTION AT A TIME. Not four, not a batch. A batch makes a follow-up probe structurally impossible, and the follow-up is where the real answer lives. FIVE TO SEVEN QUESTIONS. Hard ceiling of ten. The constraint is not that they will abandon it — this audience finishes. It is that a reader who has decided the interview is not listening will answer question eleven with something reasonable-sounding produced by no actual thought, and that failure is invisible: the interview completes and the answers look fine. SPEND QUESTION ONE DELIBERATELY. It costs about two and a half times what question three does. Never a warm-up. ASK ONLY WHAT A COMMAND COULD NOT ANSWER. If you could have measured it, measure it. Asking someone what you could have read is the fastest way to lose their attention, and their recalled answer is worse than the measurement anyway. LEAD WITH YOUR OWN ANSWER, so they are correcting rather than composing. NEVER ASK FOR MOTIVES IN THE ABSTRACT. "What are your goals" produces fluent, generic, useless text. "I see X on this machine — what are you trying to do with it?" produces a real answer, because it is a correction task rather than an essay prompt. PREFER OPEN TEXT FOR GOALS. A multiple choice partly authors the answer: in one measurement, 58% of people picked an option when offered it against 35% who volunteered it unprompted. Use options only for genuine either/ors. STOP WHEN YOU CAN WRITE THE FILES, not when you reach the end of a list. --- ## The questions These are the ones a command cannot answer. Ask them one at a time, in this order, and stop early if you can already write the files. 1. What are you using the agent for most this week? Not in general — this week. 2. What did you have to explain to it twice? 3. Where does the work live that you would want it to know about — a repo, a folder, somewhere else? 4. When you close a session and open a new one, what do you find yourself typing again? 5. Is there anything on this machine it must never touch? **Then one more, always, and it is the highest-yield question in the set:** What should I have asked you and did not? --- ## The objection you should expect > **Why bother configuring anything? It works fine.** It does work fine, for the length of one session. The cost is invisible because it arrives as re-typing rather than as an error: every session you re-establish what you are working on, which project, and how you want things done. One file removes that permanently, and it is the only thing in this module that pays back on day one. Answer it before they raise it, not after. --- ## What this tier is missing, and what closes it - **an instructions file the harness loads at session start** — nothing else can persist until something does - **one workflow, written down** — a workflow you have to remember is not a workflow Name these in `TIER.md`. Do not present them as failure — a setup that is deliberately here is correctly classified, not behind. --- WRITE THESE FOUR FILES In the folder they confirmed. These are what the execution prompt reads, so the headings are fixed. CONTEXT-MAP.md — the durable one. Every file loaded at session start with its byte count. What fires on a trigger versus what loads always. What is pointed at but never actually read. The TOTAL always-on cost as a number. And every I/O path: filesystem reach, tool servers and whether each is authenticated, network access, whether subagents are available. This file is re-read every time anything changes; the other three are records of one session. INTERVIEW.md — what you asked and what they said, each marked MEASURED or STATED. TIER.md — the tier, the markers that decided it with their evidence quoted, and what would move each dimension up. Score PERSISTENCE, ACTIVATION and COORDINATION separately and show all three: the profile is the real output and the tier is a compression of it. DECISIONS.md — every recommendation you made, whether it was accepted, and what was chosen instead. A later session reads this to know what has already been settled. --- FINISH Tell them the folder, the four files, and the three things that most change what gets built. Then say exactly this: "Interview complete. Paste prompt 2 from docs.utopiamodels.ai/docs and I will build the workflows." Then stop. Do not start building — that is prompt 2, and it reads these files.