How Using Claude to Interview You Can Help You Build Skills (and Apps)

A lot of people are getting the advice to use Claude with skills. Or better yet, as I’ve written about before, to use Claude to help you build the skills.

But what happens then?

How do you go about telling Claude what you want to do? Or what the skill should even do?

That’s where I’ve found that having Claude interview me, one question at a time, is really helpful.

Except if all you put in your prompt is “interview me, one question at a time,” your results may vary. Mine sure did.

So here’s how I’ve set up the instructions in my Claude project to get a better interview out of it. It works for a single interview, and it holds up if more than one person is involved.

What I got wrong the first time

I asked Claude to interview me about how I evaluate a product idea.

It gave me twelve questions. Numbered, organized, and honestly pretty good.

I answered the first one. Then I skimmed to the last one and answered that. The other ten sat there while I told myself I’d come back to them.

I never came back to them.

Which is a little embarrassing, since I’m the one writing about encoding expertise into systems. I wanted to do this. I still bailed after two out of twelve.

So I don’t think the trouble was the quality of the questions. A question, even a great one, hands me a blank page and asks me to fill it. And when I’m staring at a blank page about my own work, I reach for the tidy version. The version that sounds like a reasonable process instead of the messy thing I actually do at 4pm on a Thursday when a client is being weird about scope.

Then I tried it a different way.

Instead of asking me how I evaluate a product idea, I had Claude guess first: “I’m assuming you start with market size, since that’s what most people do, then work backward to whether you can reach that market affordably. Close?”

I was typing before I finished reading it.

“Not exactly. Market size is important but not the first thing I check. I start with what it might cost to step into the market, particularly in tech, because the cost to get started can be a quick killer of an idea…”

Three sentences with a reason attached. The question format never got that out of me.

I’ve started calling it the correction engine, mostly because it’s shorter than explaining it every time. I’ll correct something that’s a little bit off much faster than I’ll build something from nothing. That’s held true for everyone I’ve run this with so far, though your mileage may vary.

What I put in the instructions

Six things, and you could start with fewer if you want to try this today.

Guess, then ask. Every probe leads with a hypothesis and invites me to correct it. Sometimes I just say “yep,” and that’s useful too.

Set the guess at the conventional answer. This one took me a while to sort out. If Claude bases its guess on what I’ve already told it, my agreement doesn’t mean much. It just means it was listening. But if the guess is set at what a competent person in this field would normally do, then agreeing tells me this part is standard and Claude can fill it in on its own. Correcting it tells me I do something different, which is the part actually worth capturing.

One question at a time. Ask me ten and I’ll answer one. Also, ten at once turns my answers into summaries, and one at a time turns them into stories. The stories are where the useful stuff hides.

Start with what we’re building. A skill? An app spec? Something that has to carry real judgment, or something that mostly needs to produce a clean output? I have Claude ask this first, because it changes how deep the rest of the interview needs to go.

Go broad, then go deep only where the guess broke. Cheap guesses across the whole territory first. Then spend the remaining time on the spots where I said “no, not really.”

Ask about slow consequences. This is the one I would have skipped, and I’m glad I didn’t. Things like: what did you stop doing, and how long did it take you to work out why? Or: where do you make a call and never find out whether it was right? Those answers aren’t in any document I’ve written, because by the time the consequence showed up, I wasn’t connecting it back to the decision that caused it. It only lives in my head, which makes it worth pulling out.

One small addition that saved me some time: I ask Claude to say when it isn’t confident about what’s conventional in a particular area. Otherwise it invents a baseline, and I end up correcting things that were never the norm to begin with.

The four files that come out

This is the part that made it stick for me.

target.md holds what we’re building and whether it needs to carry judgment. Short file. I revise it when the target moves, which it does.

claims.md holds the actual substance. Each claim gets tagged: settled, or attributed to one person, or contested with a note about when each approach applies. Claude writes to it as we go rather than at the end.

open-threads.md holds everything we noticed and didn’t get to. Corrections we didn’t chase down. Questions that were obviously next when I ran out of time.

The transcripts, one per person per session, so I can trace any claim back to what was actually said.

That third file is the one I would have left out, and it turned out to matter most. My interviews don’t end because we’re finished. They end because I say “that’s it for now.” Some days I’ve got forty minutes. Some days I’ve got ten between calls.

Ten minutes only counts for something if it gets written down while it’s happening. So a short session that closes one thread and opens two is still a good session.

When I come back, Claude asks whether I want to start somewhere new or pick up one of the open threads. I like seeing what’s dangling even when I decide to go somewhere else entirely.

And when I think we’re close, I ask: do you have enough to build the skill? What comes back is a list of what’s still thin, measured against whatever is in target.md. Sometimes I build anyway. But at least I know where the holes are.

Both files are on GitHub if you’d rather start from mine than write your own: ​the instructions​, and ​the artifacts file​ that spells out those four outputs. They go into the project together. One handles how the interview runs, the other handles what gets written down.

When more than one person is involved

Steve runs partnerships on my team, and we both profile people before a first call. Both of us have been doing it a long time. When we compared what we look for, the lists barely overlapped, and I think each of us quietly suspected the other one was missing the important part.

We could have merged them into one enormous profile format that neither of us would ever fill out. Instead we kept talking about it.

The purpose of our calls turned out to be identical. Both of us are on that call to explore a partnership.

But my partnership conversations are almost always integration conversations. How would our systems connect, what’s technically possible, where does the data flow. Steve’s are implementation conversations. Who runs this, how does it get rolled out, what does the customer experience look like.

We were preparing for two different calls that happened to share a name.

That’s how we split it, and that’s how the skill got shaped. The conversation type became the branch, and each branch looks for different things.

What I took from that: the disagreement didn’t just add a rule to what we built. It changed the shape of what we built. And that shape wasn’t in either of our heads before we compared notes.

So when a second person gets interviewed, I have Claude treat whatever is already in claims.md as one person’s take rather than as settled fact. Run their own answers out first. Then bring up where things collide, and dig there.

Give it ten minutes

You don’t need to know the details of what skill to create before you start. That’s sort of the point.

Once you’ve gotten through a real interview, you can ask Claude directly what it could build from everything it has pulled together. Skills, or a spec for an app, or both. It’s been holding all of it the whole time. Let it tell you what’s in there.

So set up a project, drop in the instructions, and let Claude take a guess at something you know well. See what it gets wrong about your work.

The corrections come easier than you’d think.