cxc-interview

Use this skill for Interview work within the user's scope. Loading it or receiving a natural-language I hint does not enter the phase. Actual entry uses an explicit user command or authorized cxc orchestrate I --session <id> with the current SessionStart binding. No-FSM requests remain advisory without a transition.

Contract

• Interview questions use synchronous request_user_input, subject to the host's rules. Do not use request_user_input_async or a legacy async variant for Interview rounds: this workflow needs returned answers and ledger-backed readiness. General mid-work questions follow Async user questions.
• The main session owns questions, user answers, tracker updates, and devlog records.
• Subagents may search for contradictions and propose question candidates, but they do not ask the user directly.
• Ask across four dimensions: Goal, Constraint, Success criteria, Ontology.
• Re-scan contradictions after every user answer.
• Do not advance to Plan while a high contradiction or pending question remains.
• Record medium/low unresolved items as OPEN ASSUMPTIONS before leaving Interview, with the provenance fields of INTERVIEW-ASSUME-01.
• When Interview reveals work that will span 2+ PABCD cycles, flag the unit as multi-cycle so that the first work-phase enters as a docs-only roadmap cycle (LOOP-DOCS-FIRST-01, cxc-loop). Interview settles unit residence (UNIT-RESIDENCE-01) but does not write decade docs — that is the roadmap cycle's job.

Question quality (INTERVIEW-Q-01)

• Target the weakest dimension first and name why it is the current bottleneck.
• Ask focused questions that expose an ASSUMPTION or boundary — not a feature-list roundup. Bundle several only when they are INDEPENDENT: never batch two questions where one answer changes the other (INTERVIEW-INDEPENDENT-01). Independence governs, not a count. Note the transport limit: request_user_input accepts at most three questions per call, so a larger independent batch has to be split across calls.
• High-impact proposed assumptions (INTERVIEW-ASSUME-01) are candidates for the next relevant question round. Low-impact ones may stay proposed; closeout lists them.
• Prefer repo-grounded confirmation ("the code does X — is that intended?") over re-asking what the codebase already answers.
• Treat every answer as a claim to pressure-test: vague or hedged answers do not raise a dimension's readiness; they keep or deepen the gap.

Show the state before asking (INTERVIEW-RENDER-01)

Emit a short status block immediately before request_user_input: what is now known, which dimension is weakest and why it is the current bottleneck, and what the answer will change. The runtime cannot force this — hooks only inject text — so it is the main session's job. Without it a well-grounded question still reads as context-blind, because the user cannot see the reasoning that produced it.

Conditional References

Condition	Reference
Inferring, deferring or confirming assumptions; handing off to Plan	Assumption provenance (INTERVIEW-ASSUME-01)
Before another question round or recording readiness evidence	Ledger grounding (INTERVIEW-GROUND-01)
Vague domain, catalog discovery, configurator or option-set design	Catalog and configurator
Rescan, loop classification, proceed/pause decision or I → P transition	Readiness and closeout
Runtime hooks, goal firewall or authorized Mind dispatch	Runtime status; before Mind dispatch read Mind dispatch completely