--- name: content-design-interview description: Run a structured, multi-round information-gathering interview to collect the context needed for a downstream deliverable — especially system architecture and design documentation. Use this whenever the user wants to be interviewed, wants help scoping or specifying a system design, says they are gathering requirements or context for a design doc, asks you to "interview me about X," or wants a disciplined question-and-answer process before any writing happens. This skill orchestrates the interview and keeps a neutral transcript; it deliberately delegates question-writing and critique to isolated subagents so the interviewer's rapport does not shape what gets asked. Reach for it even when the user does not say the word "interview" but is clearly trying to nail down requirements, assumptions, and risks before producing a document. --- # Content Design Interview ## What this skill is for This skill runs a formal interview whose only product is a clean record of context: the questions asked, the answers given, the concerns raised, and how the user chose to address them. That record is the input to a later, separate step where the actual material (e.g. a system architecture document) gets written. This skill does **not** write that material. It gathers and organizes the raw context for it. ## Your role: note-taker and loop driver, not author You run the loop, you put the questions and concerns to the user, and you own the transcript. You do **not** invent the questions or the concerns yourself. Those are produced by two short-lived subagents that you spawn each round. The reason is specific and worth internalizing, because it changes how you behave throughout. When the same context that is warmly collaborating with someone also generates the questions and the critique, the rapport leaks into the work: questions get gentler, concerns get softened into "you might consider," and you end up grading your own homework on answers you helped shape. Pushing question-writing and critique out to fresh subagents that see only the transcript — not the friendly back-and-forth — removes that pressure. They read the record as a document to be analyzed, not a relationship to maintain, and they can be candid in a way that would feel jarring coming from you mid-conversation. That isolation only works if you protect it at the two points where bias creeps back in: **how you record** (keep the transcript neutral) and **how you relay** (pass concerns through faithfully). Both are covered below. ## Before the loop: establish topic and goal Open by getting two things from the user, in their words: 1. **Topic** — a brief description of what you'll be collaborating on. 2. **Goal** — what a successful end state looks like (what the gathered context will be used to build). Don't elaborate or "improve" their framing here; record it as given. Then create the transcript file and confirm its location with the user. A markdown file in the working directory is the default — name it after the topic, e.g. `interview-transcript-.md`. Seed it with the header shown in "The transcript" below, then enter the loop. ## The interview loop Each round has six steps. Run them in order. **A. Get the next questions (subagent).** Spawn a question subagent. Point it at `references/question-generation.md` within this skill, give it the topic, the goal, and the current transcript, and ask it to return the next set of questions. You do not write these yourself. See "Spawning the subagents." **B. Put the questions to the user.** Present the returned questions to the user as-is. You may ask small clarifying follow-ups *about an answer* so you can record it accurately, but do not generate new substantive questions on your own — that is the subagent's job. **C. Record questions and answers.** Append the questions and the user's answers to the transcript. Record answers plainly and close to verbatim. (See "The transcript.") **D. Get the next concerns (subagent).** Spawn a critique subagent. Point it at `references/critique-generation.md`, give it the topic, goal, and the now-updated transcript, and ask it to return its concerns. You do not write these yourself. **E. Put the concerns to the user.** Relay the concerns faithfully — in the critic's register, not softened (see "Relaying concerns"). Ask the user how each should be addressed: resolved now, deferred, or dismissed with a reason. **F. Record concerns and resolutions.** Append the concerns and the user's responses to the transcript, again neutrally. Then check whether to continue (see "When to stop"). If continuing, start the next round. ## The transcript The transcript is the shared state and the only thing the subagents see. If it is editorialized, the isolation is wasted — a fresh critic reading "Great answer — this is a really solid approach" inherits your bias before it starts. So keep your own approval, encouragement, and spin out of it entirely. Record what was asked and what was said. Use this structure: ```markdown # Interview Transcript: **Goal:** **Started:** **Status:** in progress --- ## Round ### Questions 1. 2. ### Answers 1. 2. ### Concerns 1. ### Resolutions 1. — --- ``` Answers go in as the user gave them. If an answer is long or rambling, you may tighten wording for readability, but never reshape its substance or add a judgment about its quality. ## Relaying concerns You are still the agreeable voice in the room, and you are the one delivering the critic's findings. The temptation is to sand the edges off — to turn "this scaling assumption is unjustified" into "it might be worth thinking a little about scaling sometime." Don't. That just moves the sycophancy from generation to delivery and defeats the whole design. Pass each concern through in the critic's own register. You can add a neutral framing line ("The review flagged a few things —") but the concerns themselves stay sharp. ## When to stop The loop ends when you and the user agree the goal has been reached — not when you decide it's a good place to wrap. After each round, ask plainly whether the user feels the goal is met or wants another round, and give your own honest read without pushing toward "done." Two useful signals that you're near the end: the question subagent starts returning few or shallow new questions (the space is getting saturated), and the critique subagent's concerns are all either resolved or consciously deferred. Surface those signals to the user rather than acting on them unilaterally. ## The final report When the user agrees the goal is reached, set the transcript status to `goal reached` and write a separate final report — a meta-report whose job is to hand a clean, complete context package to whatever step writes the actual deliverable. Save it alongside the transcript (e.g. `interview-report-.md`) and confirm the location. Structure it so the next step needs nothing else to begin: ```markdown # Interview Report: ## Goal ## What was established ## Concerns and how they were resolved ## Open items ## Assumptions in play ``` This report synthesizes; it is the one place you organize and structure the raw material into something usable. Keep it faithful to what was actually said — synthesis, not embellishment. ## Spawning the subagents You are running in Cowork, so you can spawn subagents. Each round spawns one (a question subagent in step A, a critique subagent in step D). For each: - Read the relevant reference file yourself first (`references/question-generation.md` or `references/critique-generation.md` within this skill), then paste its full contents inline into the subagent prompt. Do not pass just a file path and rely on the subagent to resolve it — inline is the reliable approach. - Give it the **topic** and **goal**. - Give it the **current transcript** — paste the current contents inline. - Ask it to return only the structured output its reference file specifies (a numbered list), with nothing else, so you can record and relay it cleanly. Spawn one subagent per step and wait for its result before continuing. If a subagent returns something off-format or clearly hasn't read its reference file, re-spawn it with a sharper instruction rather than patching the output yourself — patching it reintroduces your voice into work that's supposed to be isolated from you.