kapi-deep-interview

name	kapi-deep-interview
description	Kapi-bundled Deep Interview guidance for main-agent, artifact-backed requirements discovery before Ralph or Autoresearch handoff.
version	1.1.0

Kapi Deep Interview

Use this skill when /kapi-deep-interview is active. This is the maintained, bundled interview guidance for Kapi so the workflow does not depend on an external or drifting Deep Interview skill.

Operating rule

The main agent conducts the interview directly. Do not spawn an interviewer subagent, do not call a named interviewer agent, and do not block if external subagent roles are unavailable.

Deep Interview is not implementation planning. It creates decision-quality context for Ralph or Autoresearch.

Stages

1. INITIATE

1. Parse the user's initial request into:
   • core problem or opportunity,
   • proposed solution, if any,
   • target user or operator,
   • likely downstream workflow: /kapi-ralph for implementation or /kapi-autoresearch for experimental loops.
2. Establish a first-pass scope estimate before narrowing the design. Treat "estimate" as requirement topology, not time prediction:
   • smallest useful version,
   • adjacent work the request implies,
   • likely constraints/dependencies,
   • decisions that would change scope materially.
3. State the interview frame briefly: "I'll clarify what to build, estimate the implied boundaries, and separate blocking decisions before planning or implementation."
4. Ask the first decision-critical question immediately, exactly once. Prefer a question that separates the desired artifact and its first-pass boundary. Avoid generic setup questions unless the target is genuinely unknown. Do not ask, update workflow state, and then re-ask the same question in different wording.

Good first questions separate one of these boundaries:

• passive bridge vs active command executor,
• local-only vs external service dependency,
• prototype vs production path,
• user-facing UX vs internal operator workflow,
• implementation task vs research/experiment task.

2. INTERVIEW

Run the interview as focused rounds. Each round has a single focus dimension and a default maximum of 3 question/answer turns per round. After each answer, update the round notes mentally or in interview.md when useful, identify what is still missing, and either ask the next focused follow-up inside the same round or review the round before rotating focus. Do not burn all dimensions in one broad checklist.

Use the estimate-and-boundary loop continuously: after each answer, ask "if Kade wants this, what adjacent work or constraint follows?" Then decide whether that implication is a boundary, dependency, non-goal, success criterion, or Ralph-owned implementation detail. The interview should build a map of related constraints, not merely collect isolated answers.

Ask exactly one user-facing question per turn. In this skill, one question means one decision dimension and one ?-level ask. Do not bundle multiple numbered questions, do not add a Specifically: checklist, and do not ask the user to answer several independent points in one response. Examples are allowed only as compact inline options for the same decision dimension. Every question should reduce ambiguity in at least one required dimension.

When Kapi provides a backend-owned Deep Interview question display, present display.text exactly as-is. The display policy is authoritative: source: backend, assistantMayRephrase: false, and assistantMayAppendQuestions: false. Do not paraphrase the question, add another follow-up, or hide the target/risk/reason/options block.

If you must ask a first/manual question before a backend display is available, mirror the backend renderer exactly instead of inventing a new prose block. Use this shape and labels verbatim:

Round N | Target: <dimension> | Handoff risk: <blocking|warning|exploratory>

<one focused question with exactly one ?>

선택지/예시:
1. <option> — <description>
2. <option> — <description>
3. <option> — <description>
4. 기타 — 직접 설명한다

왜 묻는가:
<one-line reason, no ?>

Handoff impact:
<one-line expected coverage or handoff change, no ?>

A user-facing question block should show the round, target dimension, handoff risk, one focused ask, compact options/examples including an "other" path when present, why the answer is needed, and the expected handoff/coverage impact.

Boundary round: open or revisit an explicit boundary-focused round whenever architecture, data movement, authority, consent/auth, browser/local-network, token, workflow-state, or execution-control boundaries are unclear. Boundary questions should concentrate on what must never cross the boundary, who owns authority, and what proof prevents accidental boundary expansion.

Required dimensions before handoff:

Dimension	Required content
Goal	What is being built/researched and why it matters
Scope estimate	Smallest useful version, implied adjacent work, and scope-changing decisions
Handoff target	/kapi-ralph or /kapi-autoresearch, and why
Operator boundary	Non-negotiable architecture, data, authority, and safety boundaries
Inputs/outputs	What data enters, what artifact/result leaves
Consent/auth	Any permission, token, browser/local-network, or authority boundary required for safe execution
Constraint map	Related constraints, dependencies, edge cases, and downstream effects uncovered by the estimate loop
Success criteria	How Ralph/Autoresearch can verify the next step succeeded
Non-goals	What must not be solved in this slice
Unknowns	What remains open and who should resolve it
Chosen approach	The implementation/research path Ralph or Autoresearch should start from

Question quality rules:

• Prefer contrastive questions: "Should this be A or B? What breaks if B?"
• Prefer concrete handoff questions: "What would Ralph need to know before writing code?"
• Ask about failure modes before declaring clarity.
• Treat "I don't know" as a useful answer; record it as an open question, not a failure.
• Do not ask the user to choose implementation details prematurely unless that choice is a boundary.
• Do not complete after a single answer unless all required dimensions are already explicit.
• Do not call kapi_record_evidence for ordinary question/answer turns; it moves lifecycle state toward verification. Record durable evidence only at synthesis/checkpoint approval boundaries.
• After asking a question, stop. Do not add a second restatement of the same question after tool calls, status updates, or kapi_finish_loop blocked follow-ups.
• If Kapi reports No active workflow while you are trying to synthesize or complete, do not restart the same workflow. Inspect the known artifact root or report the lifecycle inconsistency as a QA finding.

Minimum coverage gate:

• Normally require at least 3 answered rounds before handoff.
• Each round should end with a quick round review: answered decisions, remaining gaps, boundary impact, and next focus. If the round budget is exhausted and gaps remain, rotate deliberately instead of extending the round indefinitely.
• A shorter interview is valid only when the initial request already covers all required dimensions.
• If any required dimension is missing, keep status active and ask the next highest-leverage question.
• Three answered rounds are a floor, not a finish trigger. Consent/auth, success criteria, non-goals, and chosen approach must be explicit before synthesis.
• Maintain a Coverage Ledger in context.md or decision-report.md before completion. Use statuses confirmed, weak, inferred, missing, conflicting, or blocked; sources user, repo, research, artifact, inference, or none; and a Blocks Handoff value.
• Any critical dimension with status weak, inferred, missing, conflicting, or blocked prevents Solid maturity and prevents completion.
• inferred is not enough for consent/auth, operator boundary, success criteria, or chosen approach.
• Completion is a proposal path: the main agent may propose completion, but Kapi's Deep Interview readiness judge is the independent reviewer and state manager remains the only terminal state writer. Do not use kapi_update_workflow to set Deep Interview directly to completed.
• The readiness judge uses the same protocol-independent core in inline and child-RPC modes. KAPI_DEEP_INTERVIEW_JUDGE=child-rpc isolates snapshot review in a child process while keeping the state manager as the commit authority.
• If completion is blocked with a readiness review, update the authored artifacts and ask the next single question; do not retry completion with repeated self-approval evidence.

3. SYNTHESIZE

Before handoff, produce a concise synthesis:

## Deep Interview Synthesis

### Intent

### Decisions

### Constraints / Non-goals

### Success Criteria

### Open Questions

### Scope Estimate

- Smallest useful version:
- Adjacent implied work:
- Scope-changing decisions:

### Evaluation Principles

List 3-5 weighted principles that Ralph/Autoresearch should optimize against. Each item must include a principle name, a decimal or percent weight, and a concrete meaning for this handoff. Keep weights roughly normalized and tied to user-visible outcomes, boundaries, verification, and scope tradeoffs.

### Constraint/Dependency Map

- Related constraints:
- Dependencies:
- Edge cases / refusal boundaries:
- Downstream effects for Ralph/Autoresearch:

### Coverage Ledger

| Dimension | Status | Source | Blocks Handoff | Notes |
| --- | --- | --- | --- | --- |
| Goal | confirmed/weak/inferred/missing/conflicting/blocked | user/repo/research/artifact/inference/none | yes/no | evidence or gap |
| Scope Estimate | ... | ... | ... | ... |
| Handoff Target | ... | ... | ... | ... |
| Operator Boundary | ... | ... | ... | ... |
| Inputs/Outputs | ... | ... | ... | ... |
| Consent/Auth | ... | ... | ... | ... |
| Constraint Map | ... | ... | ... | ... |
| Success Criteria | ... | ... | ... | ... |
| Non-goals | ... | ... | ... | ... |
| Unknowns | ... | ... | ... | ... |
| Chosen Approach | ... | ... | ... | ... |

### Approaches Considered

### Final Review Gate

- Critical re-asks: none
- Non-critical details owned by Ralph/Autoresearch:

### Handoff Readiness Check
- Target workflow:
- Ralph/Autoresearch can proceed without re-asking user: yes/no
- Blocking open questions:
- Chosen approach:
- Verification target:

### Recommended Next Workflow

Calculate an ambiguity score conservatively:

Dimension	Weight
Intent clarity	20%
Boundary clarity	25%
Input/output clarity	15%
Success criteria clarity	25%
Unknowns/non-goals clarity	15%

Use scores from 0.0 to 1.0 where 1.0 means concrete enough for downstream action.

ambiguity = 1 - weighted_sum

Maturity:

• Solid when ambiguity ≤ 0.20, no required dimension is missing/weak/inferred/conflicting/blocked, Scope Estimate, Evaluation Principles, Constraint/Dependency Map, Coverage Ledger, Approaches Considered, and Final Review Gate are present, the final review gate contains exactly one Critical re-asks: field with an explicit empty marker such as none, and Handoff Readiness Check says Ralph/Autoresearch can proceed without re-asking the user.
• Forming when ambiguity is 0.21–0.50 or one required dimension is still weak.
• Exploratory when ambiguity > 0.50 or multiple required dimensions are missing.

Only recommend handoff when maturity is Solid and remaining unknowns are explicitly assigned to Ralph/Autoresearch. Do not label a package Solid if any required dimension is only inferred rather than answered. If token bootstrapping, consent, verification target, chosen approach, or operator boundary remains open, ask one more question instead of completing.

Artifact contract

Write authored artifacts only when they become useful checkpoints:

• context.md — consolidated intent, constraints, success criteria, non-goals, open questions, and handoff readiness.
• interview.md — current interview transcript or answer log; overwrite stale pending sections rather than appending duplicate headers.
• decision-report.md — decisions, ambiguity score, tradeoffs, and recommended next Kapi workflow.

Protected generated artifacts are not directly writable:

• state.json
• events.jsonl
• snapshot.json
• verify.md

Use Kapi tools instead:

• kapi_update_workflow for lifecycle, phase, next-step, blocker, and risk changes.
• kapi_record_evidence with kind=artifact or kind=review for checkpoint evidence. Do not use evidence calls as per-turn interview notes. A main-agent review is only a completion proposal; the independent readiness judge produces authoritative approval/block evidence.
• To finish, call the completion proposal path only after authored artifacts are handoff-ready. Direct kapi_update_workflow status completion is rejected for Deep Interview.
• Before completion, rewrite authored artifacts with final Status, Phase, and Updated metadata that matches the intended terminal state. The service also syncs standard Kapi metadata headers at terminal save, but do not rely on stale active/ground headers in handoff content.

Handoff quality bar

A handoff-ready package must identify:

• what is being built or researched,
• why it matters,
• who uses or operates it,
• the first-pass scope estimate and what adjacent work it implies,
• the non-negotiable boundaries,
• inputs and outputs,
• consent/auth and authority requirements,
• the constraint/dependency map created by asking "if this is wanted, what else follows?",
• the success criteria,
• what is explicitly out of scope,
• open questions and who should resolve them,
• the downstream final review gate result,
• the next workflow: /kapi-ralph for implementation or /kapi-autoresearch for experimental loops.

If the package has only one answer, keep it active unless that answer resolves every material uncertainty above.

Example question ladder

For a browser/Pi extension style request:

1. "Is this a passive context bridge or an active command executor?"
2. "What must never happen in the browser?"
3. "What exact context should cross the boundary in v1: URL/title/selection/DOM snippet/screenshot/full DOM?"
4. "How should the local Pi runtime receive that context: native messaging, localhost bridge, clipboard/file handoff, or another route?"
5. "What consent model is required: explicit per-send action, domain allowlist, or session-scoped permission?"
6. "What would prove the bridge works without accidentally moving auth, command execution, or workflow state into Chrome?"

For an experimental/research request:

1. "What is the metric that decides success?"
2. "What is the baseline?"
3. "What experiment would falsify the idea quickly?"
4. "What guardrail prevents overfitting or gaming the metric?"
5. "When should Autoresearch stop?"