pacificstudio/openase/deep-interview

Deep Interview

Overview

Use this skill when the request is broad, ambiguous, or missing concrete acceptance criteria. Its job is to turn a vague idea into an execution-ready requirement brief before deeper planning or implementation begins.

When To Use

• The user wants to explore a broad idea without making hidden assumptions.
• The request lacks clear scope, non-goals, or success criteria.
• A later planning or execution step would otherwise guess at intent.
• The change touches an existing codebase and the current pattern or boundary is still unclear.

Do Not Use

• The request already names concrete files, symbols, errors, or acceptance criteria.
• The user explicitly wants to skip clarification and accept the risk.
• A complete requirement brief or implementation plan already exists.

Workflow

1. Start with context you can gather yourself.

• Inspect the codebase, docs, or surrounding ticket context before asking the user about project internals.
• Summarize what is already known and which parts are still assumptions.

1. Ask one question at a time.

• Do not batch multiple unrelated questions.
• Ask the highest-leverage unresolved question first.

1. Prioritize requirement clarity in this order.

• Intent: why the user wants the change.
• Outcome: what end state should exist when the work is done.
• Scope: how far the change should go.
• Non-goals: what should stay out of scope.
• Decision boundaries: what the agent may decide without asking again.
• Constraints: technical, business, operational, or timeline limits.
• Success criteria: how completion will be judged.

1. Pressure-test each important answer.

• Ask for an example, counterexample, or concrete signal.
• Surface the hidden assumption behind the answer.
• Force a boundary or tradeoff when the scope is still fuzzy.
• If the user is describing symptoms, steer back toward the underlying problem.

1. Keep the interview efficient.

• Prefer evidence-backed confirmation questions for brownfield work.
• Do not ask the user for facts you can inspect directly.
• Stop once the request is clear enough to plan, not after exhausting every possible question.

1. Crystallize the result into a requirement brief.

• Intent
• Desired outcome
• In-scope work
• Out-of-scope / non-goals
• Decision boundaries
• Constraints
• Testable acceptance criteria
• Open risks or residual ambiguity

1. Hand off cleanly.

• If implementation approach still needs review, hand off to a planning step.
• If the request is now concrete enough to execute, pass the brief forward as the source of truth.

Operating Rules

• Ask about intent and boundaries before implementation details.
• Do not rotate topics just for coverage when one answer is still vague.
• Revisit at least one earlier answer with a deeper follow-up before declaring the brief complete.
• Do not hand off while non-goals or decision boundaries remain implicit.
• If the user chooses to proceed early, explicitly record the residual risk.

Default Deliverable Shape

Return these sections when the interview is complete:

1. Intent
2. Desired Outcome
3. In Scope
4. Out of Scope
5. Decision Boundaries
6. Constraints
7. Acceptance Criteria
8. Residual Risks