| 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:
- Goal — What you are trying to learn (e.g., "project vision and target users").
- What is already known — Drafts from automated analysis, facts found in code. Prevents asking what you already know.
- Output target — Which file(s) the answers will land in.
- 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
- 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."
- Ask → Wait → Capture → Next loop:
- One question → wait for answer → immediately update the target file → next question.
- Stop when done — When the caller's stated goal is satisfied, stop. An optional final "anything else?" is allowed once.
- 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.
