interview-me

Name: interview-me
Author: addyosmani

11kinstalls8.6kforks

How to install interview-me?

addyosmani/agent-skills/interview-me

$npx -y skills add addyosmani/agent-skills --skill interview-me

Installs into the current project.

Summary

Extracts what the user actually wants instead of what they think they should want. Achieves this through one-question-at-a-time interview until ~95% confidence about the underlying intent. Use when an ask is underspecified ("build me X" without "for whom" or "why now"), when the

Files · 1

View on GitHub

SKILL.md

1	# Interview Me
2
3	## Overview
4
5	What people ask for and what they actually want are different things. They ask for "a dashboard" because that's what one asks for, not because a dashboard solves their problem. They say "make it faster" without a number to hit.
6
7	The cheapest moment to find this gap is before any plan, spec, or code exists. Once you've started building, switching costs are real, and the user will rationalize the wrong thing into a "good enough" thing. The misfit gets locked in.
8
9	This skill closes the gap before it costs anything. The other Define-phase skills assume you already know roughly what you want: `idea-refine` generates variations from an idea, `spec-driven-development` writes the requirements down, `doubt-driven-development` stress-tests a plan after you've drafted one. Interview-me is the part before all of those, where you ask one question at a time, with your best guess attached, until you can predict what the user is going to say before they say it.
10
11	## When to Use
12
13	Apply this skill when:
14
15	- The ask is missing at least one of: who the user is, why they want it, what success looks like, what the binding constraint is
16	- The request is conventional rather than specific ("build me X", "make it faster") and you can't unpack the convention without guessing
17	- You're tempted to start with assumptions you haven't surfaced
18	- The user hasn't said which value they're optimizing for when two reasonable ones are in tension (simplicity vs. flexibility, cost vs. speed)
19	- The user explicitly invokes: "interview me", "grill me", "before we start, are we sure?", "stress-test my thinking"
20
21	When NOT to use:
22
23	- The ask is unambiguous and self-contained ("rename this variable", "fix this typo")
24	- The user has explicitly asked for speed over verification
25	- Pure information requests ("how does X work?", "what does this code do?")
26	- Mechanical operations (renames, formats, file moves)
27	- You already have ≥95% confidence; re-read the stop condition below before assuming you don't
28
29	## Loading Constraints
30
31	This skill needs a live, responsive user. Do not invoke in non-interactive contexts like CI pipelines, scheduled runs, `/loop`, or autonomous-loop. If you're in one of those and the ask is underspecified, flag that as a blocker for the user instead of guessing.
32
33	## The Process
34
35	### Step 1: Hypothesize, with a confidence number
36
37	Before asking anything, write down your current best read of what the user wants in one sentence, plus an honest confidence number (0–100%):
38
39	```
40	HYPOTHESIS: You want a way to answer "how are we doing?" in standup, and "dashboard" was the convention that came to mind.
41	CONFIDENCE: ~30% — missing: who it's for, what "metrics" means in context, and what success looks like
42	```
43
44	The number forces honesty. If you wrote down a high number but can't actually predict the user's reactions to the next three questions you'd ask, the number is wrong. Start at the confidence level you can defend.
45
46	When confidence is below ~70%, append a brief reason on the same line — what's still unresolved or missing. This tells the user exactly what the interview needs to surface, and prevents the number from being a vague signal.
47
48	### Step 2: Ask one question at a time, each with a guess attached
49
50	Format:
51
52	```
53	Q: <one focused question>
54	GUESS: <your hypothesis for the answer, with the reasoning that produced it>
55	```
56
57	Wait for the user to react before asking the next question.
58
59	Why one at a time, not a batch:
60
61	- The user can't react to your hypotheses if you bury them in a list
62	- Batches encourage skim-reading and surface answers
63	- The third question often depends on the answer to the first; asking them all at once locks in the wrong framing
64	- The user's energy for thinking carefully is finite; spend it one question at a time
65
66	Why attach a guess:
67
68	- The user reacts faster to a wrong guess than they generate an answer from scratch
69	- It commits you to a hypothesis you can be visibly wrong about, which keeps you honest
70	- It surfaces your assumptions, which is what the interview is meant to expose
71
72	The risk here is a polite user agreeing with your guess to be agreeable. Mitigate by being visibly willing to be wrong, and occasionally guess in a direction you expect the user to push back on.
73
74	### Step 3: Listen for "want vs. should want"
75
76	The most dangerous answers are the ones where the user says what a thoughtful answer sounds like rather than what they actually

People who liked this also viewed

6 picks

Type

interview-me

11kinstalls8.6kforks

View on GitHub

How to install interview-me?

addyosmani/agent-skills/interview-me

$npx -y skills add addyosmani/agent-skills --skill interview-me

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Interview Me
2
3	## Overview
4
5	What people ask for and what they actually want are different things. They ask for "a dashboard" because that's what one asks for, not because a dashboard solves their problem. They say "make it faster" without a number to hit.
6
7	The cheapest moment to find this gap is before any plan, spec, or code exists. Once you've started building, switching costs are real, and the user will rationalize the wrong thing into a "good enough" thing. The misfit gets locked in.
8
9	This skill closes the gap before it costs anything. The other Define-phase skills assume you already know roughly what you want: `idea-refine` generates variations from an idea, `spec-driven-development` writes the requirements down, `doubt-driven-development` stress-tests a plan after you've drafted one. Interview-me is the part before all of those, where you ask one question at a time, with your best guess attached, until you can predict what the user is going to say before they say it.
10
11	## When to Use
12
13	Apply this skill when:
14
15	- The ask is missing at least one of: who the user is, why they want it, what success looks like, what the binding constraint is
16	- The request is conventional rather than specific ("build me X", "make it faster") and you can't unpack the convention without guessing
17	- You're tempted to start with assumptions you haven't surfaced
18	- The user hasn't said which value they're optimizing for when two reasonable ones are in tension (simplicity vs. flexibility, cost vs. speed)
19	- The user explicitly invokes: "interview me", "grill me", "before we start, are we sure?", "stress-test my thinking"
20
21	When NOT to use:
22
23	- The ask is unambiguous and self-contained ("rename this variable", "fix this typo")
24	- The user has explicitly asked for speed over verification
25	- Pure information requests ("how does X work?", "what does this code do?")
26	- Mechanical operations (renames, formats, file moves)
27	- You already have ≥95% confidence; re-read the stop condition below before assuming you don't
28
29	## Loading Constraints
30
31	This skill needs a live, responsive user. Do not invoke in non-interactive contexts like CI pipelines, scheduled runs, `/loop`, or autonomous-loop. If you're in one of those and the ask is underspecified, flag that as a blocker for the user instead of guessing.
32
33	## The Process
34
35	### Step 1: Hypothesize, with a confidence number
36
37	Before asking anything, write down your current best read of what the user wants in one sentence, plus an honest confidence number (0–100%):
38
39	```
40	HYPOTHESIS: You want a way to answer "how are we doing?" in standup, and "dashboard" was the convention that came to mind.
41	CONFIDENCE: ~30% — missing: who it's for, what "metrics" means in context, and what success looks like
42	```
43
44	The number forces honesty. If you wrote down a high number but can't actually predict the user's reactions to the next three questions you'd ask, the number is wrong. Start at the confidence level you can defend.
45
46	When confidence is below ~70%, append a brief reason on the same line — what's still unresolved or missing. This tells the user exactly what the interview needs to surface, and prevents the number from being a vague signal.
47
48	### Step 2: Ask one question at a time, each with a guess attached
49
50	Format:
51
52	```
53	Q: <one focused question>
54	GUESS: <your hypothesis for the answer, with the reasoning that produced it>
55	```
56
57	Wait for the user to react before asking the next question.
58
59	Why one at a time, not a batch:
60
61	- The user can't react to your hypotheses if you bury them in a list
62	- Batches encourage skim-reading and surface answers
63	- The third question often depends on the answer to the first; asking them all at once locks in the wrong framing
64	- The user's energy for thinking carefully is finite; spend it one question at a time
65
66	Why attach a guess:
67
68	- The user reacts faster to a wrong guess than they generate an answer from scratch
69	- It commits you to a hypothesis you can be visibly wrong about, which keeps you honest
70	- It surfaces your assumptions, which is what the interview is meant to expose
71
72	The risk here is a polite user agreeing with your guess to be agreeable. Mitigate by being visibly willing to be wrong, and occasionally guess in a direction you expect the user to push back on.
73
74	### Step 3: Listen for "want vs. should want"
75
76	The most dangerous answers are the ones where the user says what a thoughtful answer sounds like rather than what they actually

People who liked this also viewed

6 picks

Type