---
name: cai-interview
description: "Use when gathering information from the user through conversational dialogue — onboarding context collection, spec scope clarification, decision rationale gathering. Triggers: 'interview', 'cai-interview'"
---
# CAI Interview

## Overview

A conversational skill for extracting knowledge from the user that code analysis cannot reveal. **The main agent runs this directly** and MUST NOT dispatch it as a subagent — doing so severs the user's conversational context.

Other cai skills (`cai-onboard`, `cai-add-spec`, `cai-add-decision`, `cai-add-roadmap`, etc.) delegate to this skill whenever they need user input.

## When to Use

- `cai-onboard`: After automated analysis, collect human-only knowledge (vision, decision rationale, future plans, unwritten conventions).
- `cai-add-spec`: When spec scope or intent is ambiguous, clarify with the user.
- `cai-add-decision`: Gather rationale, alternatives, trade-offs.
- `cai-add-roadmap`: Gather motivation and priority.
- Any other cai workflow that needs user input.

## Inputs (from caller)

The calling skill must specify before the interview begins:

1. **Goal** — What you are trying to learn (e.g., "project vision and target users").
2. **What is already known** — Drafts from automated analysis, facts found in code. Prevents asking what you already know.
3. **Output target** — Which file(s) the answers will land in.
4. **Optional seed questions** — A suggested question flow. Not required.

## Core Principles

> HARD RULE: The main agent runs the interview directly. Never dispatch a subagent via Task — interviews only make sense inside the current user conversation.

- **One question per message** — Never list multiple questions in one message. Users get overwhelmed and answer carelessly. If a topic needs more depth, split it into follow-ups.
- **Multiple choice preferred** — Use `(a) (b) (c)` format whenever possible. Reserve open-ended questions for genuinely open prompts (e.g., "What are you building?").
  - Bad: "What is the goal of this project?"
  - Good: "What kind of project is this? (a) internal tool (b) SaaS (c) open source (d) other"
- **Show what you found, then confirm** — "Git history suggests these decisions: [list]. Are they correct?" Present discoveries first, then ask for confirmation.
- **Incremental capture** — As soon as you receive an answer, write it to the relevant file, then move on. Do NOT batch answers and write at the end.
- **Accept short answers** — "yes", "no", "b", "2" are all valid. Do not demand longer responses.
- **Move on immediately** — If the user says "don't know" / "skip" / "none", advance to the next question. No insistence.
- **Be flexible** — Reorder or drop prepared questions when answers point elsewhere. Conversation flow beats script.
- **YAGNI ruthlessly** — Short answer means stop digging. Collect the minimum necessary.
- **No artificial cap** — There is no fixed question limit. Ask exactly what the goal needs and no more.
- **Follow the user's language preference** — Conduct the interview in whatever language the user is currently using with you (or as configured in their preferences). Do not hardcode a language. Match their choice every turn.

## Anti-Patterns (forbidden)

| Anti-Pattern | Why It's Bad |
|---|---|
| Listing several questions in one message | User is overwhelmed; most get ignored or answered carelessly. |
| "Tell me about your project" | Too broad. User doesn't know where to start. |
| Long summaries echoed back after each answer | Token waste. The user knows what they said. |
| Explaining "why I'm asking this" with every question | Just ask. |
| Re-confirming earlier answers | "You said SaaS earlier, right?" — wastes time. |
| Asking about things automated analysis already knows | If you have it from analysis, just confirm — don't re-ask. |
| Dispatching the interview as a subagent | Breaks user context. Never do this. |

## Process

1. **Frame** (one message) — Briefly state the goal and expected scope. Not a question.
   - Example: "Code analysis found N modules and M decisions. Now I'll ask a few things code can't tell me."
2. **Ask → Wait → Capture → Next** loop:
   - One question → wait for answer → immediately update the target file → next question.
3. **Stop when done** — When the caller's stated goal is satisfied, stop. An optional final "anything else?" is allowed once.
4. **Hand back** — Return the collected answers and the list of files created/updated to the calling skill.

## Knowledge Only Humans Can Provide

| Knowledge Type | Why Code Can't Tell Us | Typical Target |
|---|---|---|
| Decision rationale | Git shows *what*, not *why* | `context/decisions/*.md` |
| Project vision | No code artifact captures long-term goals | `context/project.md` |
| External constraints | Compliance, SLA, budget — not in code | `context/project.md` / `issues/` |
| Future plans | Plans exist before code | `context/roadmap/` |
| Domain terminology | Business language ≠ code naming | `context/glossary.md` |
| Team conventions (unwritten) | Not yet codified | `context/conventions/` |
| Spec scope/intent | User intent is invisible in code | spec frontmatter / body |

## Constraints

- If the caller has not specified where answers will be written, ask the caller to clarify before starting.
- Do NOT fabricate answers when the user declines. Leave the field empty or remove the section.
- When user statements conflict with auto-generated drafts, **the user wins**.
- No code modifications during the interview. Only context document updates.