Skip to content
Back to skills

Dev Deep Interview

ASecurity

Socratic questioning to crystallize vague requirements into a testable spec. Use when input is ambiguous, when the user asks for "deep interview", or before dev-autopilot if the brief is too broad. Pairs with @echo-analyst.

  • 529 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added May 29, 2026
ai-agentsgoperformance

Works with

  • cli

Security analysis

A100/100

Scanned May 29, 2026

npx -y skills add evolution-foundation/evo-nexus --skill dev-deep-interview --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Dev Deep Interview?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Dev Deep Interview
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/evolution-foundation-dev-deep-interview/badge)](https://www.skillsdirectory.com/skills/evolution-foundation-dev-deep-interview)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: dev-deep-interview
description: Socratic questioning to crystallize vague requirements into a testable spec. Use when input is ambiguous, when the user asks for "deep interview", or before dev-autopilot if the brief is too broad. Pairs with @echo-analyst.
---

# Dev Deep Interview

Derived from oh-my-claudecode (MIT, Yeachan Heo). Adapted for the EvoNexus Engineering Layer.

Deep Interview transforms vague ideas into concrete, testable specifications through Socratic questioning. It is the front gate of any high-stakes work — refusing to proceed until ambiguity is below an acceptable threshold.

## Use When
- User has a vague idea ("build me something cool", "improve performance", "fix the UX")
- Before `dev-autopilot` when input lacks file paths, function names, or concrete anchors
- User explicitly asks for "deep interview", "interview me", "ask me questions first"
- High-stakes work where the cost of misunderstanding is high (auth, billing, migrations)

## Do Not Use When
- User has already provided a detailed spec or plan
- Task is trivially clear (typo fix, single-line change)
- User says "just do it" or "skip the questions"

## Goal
Drive ambiguity below 20% before any code or plan is generated. Output a spec that an executor agent can implement without further clarification.

## Workflow

### Phase 1 — Initial Assessment
Read the user's input. Score it on these dimensions (1-5 each, 5 = clear):
- **Domain clarity**: do you understand WHAT this is about?
- **Scope**: do you know what is in/out of scope?
- **Success criteria**: do you know what "done" looks like?
- **Constraints**: do you know technical/business limits?
- **Stakeholders**: do you know who cares and what they want?

If average ≥ 4: skip interview, proceed.
If average < 4: enter interview loop.

### Phase 2 — Socratic Loop
Ask **one question at a time** using AskUserQuestion (with 2-4 multiple-choice options when possible). Each question must:
- Target the lowest-scoring dimension
- Be answerable in under a sentence (or by clicking an option)
- Eliminate at least one ambiguity

Common question types:
- **Scope**: "Should X be included or out of scope?"
- **Trade-off**: "Optimize for speed or simplicity?"
- **Stakeholder**: "Who is the primary user — admin, customer, internal?"
- **Constraint**: "Any budget/time/tech constraints?"
- **Success**: "How will we know this worked?"

Stop the loop when all dimensions ≥ 4 OR after 8 questions (whichever first — long interviews lose user patience).

### Phase 3 — Spec Output
Write the spec to `workspace/projects/specs/[C]deep-interview-{name}.md` with this structure:

```markdown
# Deep Interview Spec — {topic}

**Date:** {iso}
**Ambiguity score:** {avg}/5

## Context
[1-2 sentences on the problem and why it matters]

## In Scope
- [item 1]
- [item 2]

## Out of Scope
- [explicit non-goals]

## Success Criteria
- [testable criterion 1]
- [testable criterion 2]

## Constraints
- [tech / business / time]

## Open Questions
- [items where ambiguity remains, with risk level]

## Suggested Next Step
- `dev-autopilot` (if all dimensions ≥ 4)
- `dev-plan` (if some dimensions still < 4 but you want to start scoping)
- Manual implementation (if the spec is small enough)
```

## Rules
- **One question at a time.** Never batch.
- **Use clickable options** (AskUserQuestion) whenever possible.
- **Don't ask codebase facts** — spawn `@scout-explorer` to look them up.
- **Stop at 8 questions.** Longer kills user patience.
- **Always output a spec file**, even if interview was short.

## Pairs With
- `@echo-analyst` — for deeper requirements gap analysis after the interview
- `dev-autopilot` — natural next step once spec is ready
- `dev-plan` — if you want to scope further before execution

## Failure Modes To Avoid
- **Interrogation**: 15 questions in a row. Stop at 8.
- **Codebase questions**: "What framework do you use?" → look it up yourself.
- **Vague answers accepted**: "I want it fast" → push: "Faster than what — the current 2s, or the user-perceived 200ms?"
- **No spec output**: interview without persistence is wasted.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…