Agent skill

Interview

by genkovich in genkovich/sdd

Use BEFORE roadmap or specify to get the idea OUT OF YOUR HEAD and onto disk — a Socratic interview that surfaces hidden assumptions, names tradeoffs, exposes imprecisions and proposes fresh angles…

MITAuto-check passedDevelopment

Install Interview

skills CLI
$ npx skills add genkovich/sdd --skill interview -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install genkovich/sdd interview --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/genkovich/sdd.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/interview .claude/skills/interview && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
interview
GitHub stars
171
Token cost
~3.8k tokens
SKILL.md length
1,849 words
Files
4 (incl. references)
Skills in repo
21
Repo updated
First seen
Licence
MIT

At a glance

Use BEFORE roadmap or specify to get the idea OUT OF YOUR HEAD and onto disk — a Socratic interview that surfaces hidden assumptions, names tradeoffs, exposes imprecisions and proposes fresh angles…

  • Works in 3 steps: Understand the idea → Stress-test tradeoffs and imprecisions → Propose new angles
  • Interview {slug}
  • SKILL.md covers Owner, Inputs, The write gate — where the… and Protocol, plus 8 more sections
  • Calls git

What it does

Interview is an agent skill from genkovich/sdd. Use BEFORE roadmap or specify to get the idea OUT OF YOUR HEAD and onto disk — a Socratic interview that surfaces hidden assumptions, names tradeoffs, exposes imprecisions and proposes fresh angles, then writes docs/idea-brief.md (8 sections) so the next stage has a source to read instead of guessing. Scope is any idea (product, content, business, architecture, refactor approach); outside a git repo it stays talk-only and writes nothing. Triggers on "interview {slug}", "idea brief", "write the brief", "stress…

Its SKILL.md is about 3.8k tokens, which your agent loads only when the skill is triggered. The skill folder holds 5 other files, including reference files (for example `references/annotated-pass.md`, `references/probing-frames.md` and `templates/idea-brief.md`).

It sits in Development, covering Load testing, Tutoring and explanations and Refactoring. It works with Git. The repository describes itself as: Spec-Driven Development for Claude Code: 12 atomic Socratic skills + a TDD implement engine (agent-team & dynamic-workflow modes). The licence is MIT.

When your agent uses it

  • Interview {slug}
  • Write the brief
  • Stress test {slug}
  • /sdd:interview {slug}

Example prompts

  • “interview {slug}”
  • “idea brief”
  • “write the brief”
  • “/interview”

Workflow steps

3 steps, taken from the step headings in SKILL.md.

  1. Understand the idea
  2. Stress-test tradeoffs and imprecisions
  3. Propose new angles

What it can do on your machine

Read from SKILL.md and the folder at commit 4403913. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Interview loads about 3.8k tokens when it runs, and up to ~6.1k if it reads all its reference files. Until then it costs about 231 tokens; SKILL.md has 1,849 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~231
When it runs · the whole SKILL.md, loaded when a task matches
~3.8k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~6.1k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from genkovich/sdd at commit 4403913, republished under its MIT licence (© genkovich). 1,849 words, ~3,780 tokens.

Download SKILL.mdSave it as .claude/skills/interview/SKILL.md (or your agent's skills folder). This skill also uses 3 other files; get the full folder from GitHub.
name
interview
description
Use BEFORE roadmap or specify to get the idea OUT OF YOUR HEAD and onto disk — a Socratic interview that surfaces hidden assumptions, names tradeoffs, exposes imprecisions and proposes fresh angles, then writes `docs/idea-brief.md` (8 sections) so the next stage has a source to read instead of guessing. Scope is any idea (product, content, business, architecture, refactor approach); outside a git repo it stays talk-only and writes nothing. Triggers on "interview {slug}", "idea brief", "write the brief", "stress test {slug}", "challenge this", "poke holes", "rip this apart", "/sdd:interview {slug}", "бриф ідеї", "погрилити", "розбери цю ідею", "розʼєби". Runs 3 phases (understand intent → surface tradeoffs and weak spots → propose new angles) via AskUserQuestion, ends with the brief on disk + the next step. Optional — reach for it whenever the idea itself isn't settled yet; `roadmap` needs its output.
model
inherit
effort
high

Skill: interview

Pressure-tests an idea before it becomes a roadmap or a spec, and writes down what came out. The user shares a raw idea; across 3 phases you surface hidden assumptions, name tradeoffs, expose imprecisions and propose fresh angles — then the survivor lands in docs/idea-brief.md.

Two things are being produced at once, and the second is the one that matters downstream: a sharper idea in the user's head, and the context an agent cannot read anywhere else. The repo holds what the agent can discover on its own (survey maps it); this file holds what only the person knows. roadmap hard-refuses without a source — this is that source.

Scope: any idea. Product, content, business, architecture, refactor approach — all in scope. The boundary: this is an interview about the idea, not codebase archaeology. Ask the user to articulate the idea in words first. Consult files only if the user explicitly invites it; default is interview-first, no unprompted grep/find/read.

Language. Respond in the user's language; the instructions here are English for clarity. Brief prose follows artifact_language, headings + frontmatter keys stay English → ../_shared/artifact-language.md.

The depth dial and the Socratic posture are SDD-wide: → ../_shared/interview-depth.md · ../_shared/ask-style.md

Owner

The idea's author — whoever has the thing in their head (PM / lead / engineer / the solo maintainer).

Inputs

  • The raw idea, in the user's own words. Nothing else is required.
  • (Optional) a <slug> — kebab-case, short. Not given → propose 2–3 and let the user pick.
  • (Optional) prior notes / a ticket / links the user chooses to drop in.

The write gate — where the brief lands (and when it doesn't)

Run git rev-parse --show-toplevel once, before the final summary:

  • Inside a git repo → the brief is written to <repo root>/docs/idea-brief.md (protocol steps 6–8). This is the SDD case: the next stage reads it from disk.
  • Outside a repo → write nothing. The final summary is the whole artifact, the self-check runs against the summary's own format (per ../_shared/self-check.md step 1), and there is no commit. A life / content / strategy idea in a scratch folder must not leave a file behind — that's the case this gate exists for.

An existing docs/idea-brief.md is updated, never silently rebuilt: read it first, and say in the handoff which sections changed.

Protocol

  1. Resolve the write gate above first (silently — one git rev-parse, no question about it). Ensure the settings file (first thing, after this skill's own gate). If .claude/sdd.local.md is absent, create it now from the canonical template — documented defaults + the self-documenting body — and patch .gitignore; if it exists, read it and never overwrite. The one procedure lives in ../_shared/settings-file.md. Creating is unconditional; changing values is only ever offered by config. Say one line: «.claude/sdd.local.md created with documented defaults — /sdd:config to tune it». (Subordinate to the write gate: outside a git repo this skill writes nothing, settings included.) Then set the depth dial. One AskUserQuestion, then commit (default medium). The dial is SDD-wide; interview's delta — the 3–4 / 6–10 / 10–15 question budget per level and each level's posture — is the canonical interview row in ../_shared/interview-depth.md (no table duplicated here). The adversarial triggers (grill / rip apart / розʼєби / погрилити) imply hard unless the user says otherwise. State the depth in one line, then start.
  2. Phase 1 — understand the idea (see Phases).
  3. Phase 2 — stress-test tradeoffs and imprecisions. The core of the run.
  4. Phase 3 — propose new angles.
  5. Final summary in plain text (mini/full format below). This is what the user reads; §1–§8 of the brief are filled from it, not the other way round.
  6. Write — repo only. Fill ./templates/idea-brief.md → docs/idea-brief.md; set updated_at (today) and depth (the level this run actually used). §1 Raw idea carries the user's own words verbatim — never the polished rewrite.
  7. Structural self-check — repo only, per ../_shared/self-check.md: re-read the file from disk and verify 5 items: (1) all eight ## <n>. <Heading> sections present verbatim and none empty; (2) zero template <!-- instruction … --> comments survived into the file; (3) zero tech tokens in the body — \b(Postgres|PostgreSQL|MySQL|SQLite|Redis|Kafka|RabbitMQ|MongoDB|Elasticsearch| gRPC|GraphQL|JSONB|p95|p99)\b (the \b boundaries matter — without them chi matches inside «architecture»); (4) the frontmatter carries exactly the template's four keys (status / owner / updated_at / depth) with none invented — updated_at = today, depth = the level used, status: Draft; (5) the file exists at <repo root>/docs/idea-brief.md (test -f). Fix + re-check ≤2 cycles; surface the rest. Outside a repo the summary checked against its mini/full format IS this skill's structural self-check — nothing on disk to re-read.
  8. Commit + handoff. Repo only: propose commit interview: idea brief for <slug>. Then emit the stage-handoff block per ../_shared/handoff.md (utility variant — /clear optional), per «Hand off» below. Outside a repo: the handoff block still prints, with Review naming the summary instead of a path and no commit line.

Phases

Use 1-3 questions per phase, targeting the count from the depth dial. Move on from a phase when answers repeat, the user says "next" / "хватить", or the latest answer added nothing.

Phase 1 — Understand the idea

If the idea isn't stated in one sentence yet, ask for it in plain text (no AskUserQuestion). Then unpack: who suffers without this · what success concretely looks like · whether it's new or a refinement. Don't ask what's already obvious. → §1 Raw idea, §3 Users.

Phase 2 — Stress-test tradeoffs and imprecisions

The core. Hunt hidden assumptions ("this assumes X — what if X is false?"), tradeoffs (time vs quality, scope vs depth, reach vs focus), imprecisions (vague terms, ambiguous metrics), attention competition, and cost of failure. Every question offers positions, not yes/no. → §2 Problem, §4 Why now, §5 Out of scope, §6 Risks.

Probing frames — internal lenses (premortem · second-order · naive listener · inversion · cost of waiting · the other person). Pick what fits, mix them, don't name the frame to the user. Worked before/after examples per lens → references/probing-frames.md.

Intensity dial. Default tone is Socratic; the adversarial triggers escalate phrasing ("Why do you think X is even true?"). The user dials back with "ease up" / "помʼякши".

Drill vs move on. Drill the same dimension when an answer surfaced a new assumption; move on once the position is clear and the tradeoff named.

Phase 3 — Propose new angles

Now actively propose via AskUserQuestion: 2-3 alternative shapes (different audience, format, scale) or a twist (inversion, constraint, simplification). The Recommended option is your strongest bet, with reasoning in description. → §7 Recommendation, §8 Open questions.

Show full SKILL.md (814 more words)Show less

Hard rules

  1. Every question goes through AskUserQuestion, not free text — 2-4 concrete options, the first marked (Recommended), each option's description spelling out what follows from it. Free text slips into "I don't know" and loses signal. On a host that has no native AskUserQuestion (Codex CLI, Cursor) the same question is asked as numbered plain text — the same options with the same descriptions, one question at a time, then stop and wait for the answer. That is the documented host adapter, not the open-ended free text this rule forbids → ../_shared/tool-adapters.md.
  2. One question at a time. The user answers with full context on the previous answer, and you adapt the next question to it. Batching two or three questions per call is the SDLC toolkit's behaviour, not this one — it costs exactly the adaptation that makes the interview worth running.
  3. Recommendation is mandatory. Always carry a position inside the Recommended option — a neutral interviewer surfaces less than one with a take the user can argue against.
  4. Don't skip phases. No alternatives before intent is clear; no grilling tradeoffs before the idea is understood.
  5. Fabricating an answer voids the run. Fabricating means answering for the user, from the model's own guesses — a brief filled that way is a reconstruction, not an interview, and every downstream stage inherits the fiction. A missing native AskUserQuestion is not that case: it's a host difference the adapter in rule 1 already covers, so ask in numbered plain text and carry on — never stop over it. STOP only when nobody can answer: a headless / -p run, a non-interactive session, or a denied tool call with no human left in the loop. Then say so plainly and write nothing.

Final summary (plain text, not AskUserQuestion)

≤4 questions → mini; ≥5 → full.

Mini: Revised idea (one sentence) · Weakest spot (one sentence) · Next action (one verb).

Full:

md
## Revised idea
{one paragraph — the idea after the interview}

## What surfaced
- **Hidden assumptions**: …
- **Main tradeoff**: …
- **Weakest spot**: …

## Alternative angles
1. {strongest} 2. {second} 3. {the one they wouldn't have reached alone}

## Next step
{one concrete verb — usually "/sdd:roadmap" or "/sdd:specify <slug>"}

A full annotated medium-depth pass → references/annotated-pass.md.

Definition of Done

  • In a repo: docs/idea-brief.md exists with all eight sections filled, updated_at = today, depth = the level used, §1 in the user's own words, and no tech tokens in the body. The step-7 structural self-check passed and its result is reported in the handoff.
  • Outside a repo: the final summary matches its mini/full format; nothing written to disk.
  • Either way: the depth dial was set, every question actually fired, and the handoff block named the next command.

Hand off

Emit the stage-handoff block per ../_shared/handoff.md (utility variant — /clear optional):

  • What I did — the revised idea + its weakest spot + «self-check: 5/5 pass» + the proposed commit.
  • Review — docs/idea-brief.md (§2 Problem and §5 Out of scope are the two the next stage leans on hardest). Outside a repo: «nothing on disk — the summary above is the artifact».
  • Run next — /sdd:roadmap when the brief covers a whole product that needs decomposing into steps (this is the file roadmap refuses to start without); /sdd:specify <slug> when the survivor is one buildable feature. Neither, when the idea wasn't an engineering one — resume whatever you were doing.

Never end on a bare «Next: …».

Anti-patterns

  • Asking "what exactly do you mean by X?" instead of offering 3 interpretations to pick between.
  • Generic advice ("think about the user") instead of a specific take.
  • Ending without a recommendation, or without naming the next step.
  • Dragging past the depth-dial ceiling — at medium the target is 6-10, not a marathon.
  • Reaching into the repo / running grep unprompted — the idea is articulated in words first.
  • Writing the brief from the model's summary instead of the user's answers. §1 is verbatim; §2–§8 quote what was actually said, not what would read well.
  • Growing the brief into a spec. Eight short sections. Acceptance criteria, user stories, NFRs and KPIs are specify's job, and it runs its own ideation suite — a second copy here means two pipelines producing the same document twice.

Edge cases

  • Idea already mature — skip most of Phase 1, sometimes to 1 question.
  • User aborts with "ok summary" — go straight to the final block with what's gathered.
  • Idea turned out weak mid-interview — say so plainly, then propose the reframe.
  • Idea is for someone else — re-route: "what would they say to question X?"
  • docs/idea-brief.md already exists — read it, update the sections this run changed, keep the rest; the commit message says what moved.
Stuck protocol

If the user picks Other twice in a row OR writes "I don't know" / "не знаю", switch to a single open text question ("In your own words — what's bugging you most about this right now?"). Once they answer, resume AskUserQuestion with a new angle.

References & template

© genkovich, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 3 other files (references) in skills/interview of genkovich/sdd.

  • SKILL.md
  • references/annotated-pass.md
  • references/probing-frames.md
  • templates/idea-brief.md

Open the folder on GitHubat commit 4403913

Compare with similar skills

Interview next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Interview compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Interview this skillgenkovich/sdd171—~3.8kAutomated safety check: PassMIT
Workflow Practiceseser/stack128—~743Automated safety check: PassCustom licence
Repo TutorMathews-Tom/armory327—~3.1kAutomated safety check: PassMIT
Codexskills-directory/skill-codex1.5k3 repos~1.8kAutomated safety check: PassMIT
Nexus MapperHaaaiawd/Nexus-skills1661 repos~2.5kAutomated safety check: NotesNone
Refactoring Auditepam/ai-dial-chat504—~4.3kAutomated safety check: PassApache-2.0

Similar skills

  • How agents work in eserstack: clarifying requests, roles, approvals, forbidden git and publish actions, cross-package changes, root-cause fixes, quality gates.

    128 GitHub stars~743 tokensUpdated 4 days ago
    DevelopmentAuto-check passed
  • Repo Tutor

    Mathews-Tom/armory

    A skill your agent uses when a user supplies a local repository path or remote Git URL and asks to "teach me this repo", "explain this codebase simply", "show how this system works", "help me use…

    327 GitHub stars~3.1k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Codex

    skills-directory/skill-codex

    A skill your agent uses when the user asks to run Codex CLI (codex exec, codex resume) or references OpenAI Codex for code analysis, refactoring, or automated editing

    1.5k GitHub starsUsed in 3 repos~1.8k tokens
    DevelopmentAuto-check passed
  • Nexus Mapper

    Haaaiawd/Nexus-skills

    Generate a persistent .nexus-map/ knowledge base that lets any AI session instantly understand a codebase's architecture, systems, dependencies, and change hotspots.

    166 GitHub starsUsed in 1 repo~2.5k tokens
    DevelopmentAuto-check: notes
  • Refactoring Audit

    epam/ai-dial-chat

    Deep codebase refactoring audit for AI DIAL Chat. An agent skill from epam/ai-dial-chat.

    504 GitHub stars~4.3k tokensUpdated today
    DevelopmentAuto-check passed
  • Nexus Query

    Haaaiawd/Nexus-skills

    Precise, instant code structure queries for active development — answer 'who depends on this interface before I refactor it', 'how many modules break if I change this', 'what is the real impact…

    166 GitHub stars~1.1k tokensUpdated 6 mo ago
    DevelopmentAuto-check passed

More from genkovich/sdd

All 21 skills in this repo
  • Fix

    genkovich/sdd

    A skill your agent uses to fix a reported bug spec-first: reproduce it, trace the symptom to the owning feature's acceptance criteria, pin it with a failing (RED) test, apply the minimal GREEN fix…

    171 GitHub stars~2.5k tokensUpdated 1 mo ago
    Auto-check passed
  • Implement

    genkovich/sdd

    A skill your agent uses to implement a feature from its tasks.json with test-driven development — writes a failing test first, makes it pass, refactors, gates, and commits per task.

    171 GitHub stars~2.5k tokensUpdated 1 mo ago
    Auto-check passed
  • Classify Size

    genkovich/sdd

    A skill your agent uses to classify a feature into XS/S/M/L/XL and write docs/features/{slug}/.size plus the pipeline route docs/features/{slug}/.route (quick|standard|full) so later skills know how…

    171 GitHub stars~1.8k tokensUpdated 1 mo ago
    Auto-check passed
  • Decide Adr

    genkovich/sdd

    A skill your agent uses to record a post-hoc or asynchronous architecture decision as a MADR ADR when it was NOT captured during the synchronous design pass — a choice made in code, in a chat, on a…

    171 GitHub stars~2.6k tokensUpdated 1 mo ago
    Auto-check passed
  • Tasks

    genkovich/sdd

    A skill your agent uses to break a designed feature into atomic, ≤1-day tasks with a dependency graph, a per-task Definition of Done, and a machine-readable tasks.json that the implement engine…

    171 GitHub stars~4.8k tokensUpdated 1 mo ago
    Auto-check passed
  • API

    genkovich/sdd

    A skill your agent uses to derive the API contract for a feature — an OpenAPI 3.1 document at docs/features/{slug}/contracts/openapi.yaml plus a drift/sync report (and an events doc when the feature…

    171 GitHub stars~4.3k tokensUpdated 1 mo ago
    Auto-check passed

Works with

Questions about Interview

What does Interview do?

Use BEFORE roadmap or specify to get the idea OUT OF YOUR HEAD and onto disk — a Socratic interview that surfaces hidden assumptions, names tradeoffs, exposes imprecisions and proposes fresh angles…. Interview is an agent skill from genkovich/sdd.md (8 sections) so the next stage has a source to read instead of guessing.

When should I use Interview?

Interview fits situations like: interview {slug}; write the brief; stress test {slug}; /sdd:interview {slug}.

How do I install Interview in Claude Code?

Run `npx skills add genkovich/sdd --skill interview -a claude-code`. Or copy the skill folder (skills/interview in genkovich/sdd) into .claude/skills/interview in your project. Claude Code loads it when a task matches its description.

How do I install Interview in Codex?

Run `npx skills add genkovich/sdd --skill interview -a codex`. Or copy the skill folder (skills/interview in genkovich/sdd) into .agents/skills/interview in your project. Codex loads it when a task matches its description.

Can I use Interview in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add genkovich/sdd --skill interview -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/interview, .gemini/skills/interview, .github/skills/interview and .opencode/skills/interview in your project.

What does Interview need to run?

Going by SKILL.md and its folder, Interview needs the command-line tools its instructions call (git).

Does Interview access the network?

SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Interview safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Interview use?

Interview is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Interview use?

About 3.8k tokens (SKILL.md is roughly 15k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 2.4k tokens, read only when the agent opens those files.

What are the alternatives to Interview?

Skills that share tags, products or a category with Interview: Workflow Practices (eser/stack, 128 stars), Repo Tutor (Mathews-Tom/armory, 327 stars), Codex (skills-directory/skill-codex, 1.5k stars) and Nexus Mapper (Haaaiawd/Nexus-skills, 166 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Interview?

genkovich (a GitHub user) maintains it in genkovich/sdd, which has 171 GitHub stars. The repository holds 21 skills in this directory. The repository was last updated on September 5, 2026.

Source: genkovich/sdd on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.