interview

Prevent building the wrong thing. Discover user's intent (WHY), validate assumptions, and agree on approach (WHAT) before taking action.

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "interview" with this command: npx skills add panaversity/claude-code-skills-lab/panaversity-claude-code-skills-lab-interview

Interview Skill

Prevent building the wrong thing. Discover user's intent (WHY), validate assumptions, and agree on approach (WHAT) before taking action.

What This Skill Does

  • Discovers INTENT behind surface requests (WHY they want it)

  • Surfaces and validates AI's assumptions before acting

  • Explores solution options informed by intent

  • Reaches mutual agreement on both problem and solution

  • Works for any context: software, documents, brainstorming, automation

What This Skill Does NOT Do

  • Follow rigid scripts

  • Skip to implementation without understanding

  • Accept surface requests without exploring intent

  • Make assumptions without validating them

Core Problem This Skill Solves

AI builds the wrong thing because it:

  • Takes surface requests literally without understanding intent

  • Makes hidden assumptions it never validates

  • Proceeds without confirming alignment

This skill ensures:

  • Intent (WHY) is discovered, not just request (WHAT)

  • Assumptions are surfaced and validated

  • Both problem and solution are agreed before proceeding

The WHY + WHAT Model

Surface WHAT → Discover WHY → Surface Assumptions → Informed WHAT → Agree on Both → Proceed

Phase Purpose Example

Surface WHAT Capture initial request "Add dark mode"

Discover WHY Uncover intent/problem "Eye strain for night workers"

Surface Assumptions Expose AI's hidden assumptions "Assuming web app, not mobile"

Informed WHAT Solution options based on WHY "Dark mode + auto-brightness + schedule"

Agree on Both Confirm problem AND solution "Solving eye strain via dark mode with auto-switch"

When to Trigger

Trigger Example

Explicit invocation /interview , "let's clarify"

Request could be misunderstood Ambiguous, complex, or multi-part requests

Recommendations needed "What should I use for..."

Brainstorming "Help me think through..."

High-stakes work Where wrong output wastes significant effort

Don't over-trigger: Simple, clear requests don't need full discovery.

Discovery Flow

Before Starting

Gather available context before asking questions:

Source Gather

Conversation User's stated request, prior context

Available Context Information already shared in session

Skill References Question patterns from references/

  1. Surface WHAT

Capture the initial request clearly.

"Let me make sure I understand - you're asking for [X]?"

  1. Discover WHY

This is the critical step most AI skips.

Go beyond WHAT to understand WHY:

Ask To Discover

"What problem does this solve?" The real need

"Why now?" Urgency and context

"What happens if we don't do this?" Stakes and priority

"Who benefits and how?" Users and value

"What led to this request?" Background and triggers

Techniques for WHY:

Laddering - Dig into abstract goals:

"Dark mode" → "Why?" → "Eye strain" → "Why an issue?" → "Night shift workers"

5 Whys - Uncover root need:

"Export feature" → Why? → "Share reports" → Why? → "Stakeholder reviews" → Root need

Structuring Clarifications:

When presenting multiple questions, distinguish must-know from nice-to-know:

Required Clarifications

  1. [Critical question - blocks progress]
  2. [Critical question - affects core approach]

Optional Clarifications (if relevant)

  1. [Nice-to-know - can assume reasonable default]

Note: Keep to 1-4 questions per round. Build on answers.

  1. Surface Assumptions

This prevents "builds wrong thing."

AI always makes assumptions. Surface them explicitly:

"I'm assuming:

  • This is for [platform/context]
  • Users are [type]
  • We need to support [X] but not [Y]
  • [Other assumption]

Are these correct?"

Common hidden assumptions:

  • Technology/platform

  • User expertise level

  • Scale/performance needs

  • Integration requirements

  • What's in vs out of scope

  1. Informed WHAT

Now that WHY is clear, explore WHAT options:

"Given that you need [WHY], we could:

  1. [Option A] - [trade-off]
  2. [Option B] - [trade-off]
  3. [Option C] - [trade-off]

Which fits your intent best?"

Key: Options should address the WHY, not just the surface WHAT.

  1. Agree on Both

Confirm understanding of BOTH problem and solution:

Understanding

Problem (WHY): [What we're solving and why it matters]

Solution (WHAT): [What we'll build/do]

Key decisions:

  • [Decision 1]
  • [Decision 2]

Not included: [Explicit scope boundaries]

Does this capture it correctly?

Only proceed after explicit confirmation.

Depth Check

How do you know understanding is deep enough?

Surface Understanding (NOT enough)

  • Can repeat what user asked for

  • Know the immediate request

  • Haven't explored why

Deep Understanding (ENOUGH)

  • Know WHY they want it, not just WHAT

  • Know what problem it solves

  • Assumptions are surfaced and validated

  • Know who benefits and how

  • Know what's explicitly out of scope

  • Could explain it to someone else accurately

  • User confirmed understanding is correct

Test: If you proceeded now and built something, would user say "yes, that's what I meant" or "no, you misunderstood"?

Assumption Categories

Surface assumptions in these areas:

Category Example Assumptions

Context Platform, environment, existing systems

Users Who they are, expertise level, needs

Scale Volume, performance requirements

Scope What's included vs excluded

Quality Standards, constraints, requirements

Timeline Urgency, phases, dependencies

Anti-Patterns

Anti-Pattern What Happens Fix

Skip WHY Build wrong solution Always ask why before how

Hidden assumptions Surprise misalignment Surface and validate explicitly

Accept surface request Miss real need Dig deeper with laddering/5 whys

Proceed without confirm Waste effort Get explicit "yes, proceed"

Over-question simple requests Annoy user Match depth to complexity

Tool Adaptation

Use whatever tools are available:

Goal Approach

Ask questions Interactive tools if available, otherwise conversation

Research context Web search if needed and available

Present options Structured choices if available

The skill describes WHAT to do. The agent uses available tools.

Output: Understanding Summary

Match formality to situation:

Quick (simple requests):

Got it: [WHAT] to solve [WHY] Proceeding with [approach]. Confirm?

Standard (most cases):

Understanding

Problem (WHY): [Intent and problem being solved] Solution (WHAT): [What we'll do] Key points: [Important details] Not included: [Scope boundaries]

Ready to proceed?

Detailed (complex work): See references/summary-templates.md

Quick Reference

  1. Surface WHAT → "You're asking for X?"
  2. Discover WHY → "What problem does this solve?"
  3. Surface assumptions → "I'm assuming A, B, C - correct?"
  4. Informed WHAT → "Given WHY, we could do X, Y, or Z"
  5. Confirm both → "So we're solving [WHY] by doing [WHAT]?"
  6. Proceed → Only after explicit confirmation

Reference Files

File Purpose

references/question-patterns.md

Techniques for discovering WHY and surfacing assumptions

references/anti-patterns.md

Common mistakes that lead to building wrong thing

references/summary-templates.md

Output formats for different situations

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

Coding

browsing-with-playwright

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

doc-coauthoring

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

internal-comms

No summary provided by upstream source.

Repository SourceNeeds Review