The Third Time I Typed the Same Prompt, I Wrote a Skill
While turning a focus group into a case study, I kept pasting the same long prompt into Claude. So I turned it into a skill. Here’s how I write skills with Claude’s help, why I keep them small and focused, and how this one cut my interview analysis from three days to two hours.
3min read
The third time I pasted the same list of instructions into Claude, I stopped and asked myself why I was still doing this by hand
| Context |
A skill is a saved set of instructions that Claude can reuse, so you don’t have to explain the same task every time. I’d been using skills more and more, but this was the moment it really clicked.
I was turning a focus group I ran in my previous role as a product designer into a case study. Every new chat started the same way: the same long prompt, with small changes.
Here’s what I kept asking for:
Translate transcripts and quotes from Farsi to English, so I can share them with people who don’t speak Farsi
Group the findings into 3 to 6 themes, and show which quotes shaped each theme and how often they came up
Pull out pain points and insights from the transcripts and quotes
Show how often each pain point appears, with one or two quotes that support it
Use only what’s in my input. No assumptions or suggestions of its own
Put everything into one report, with a clear header for each section
Suggest next steps
So I turned it into a skill.
Along the way, I noticed that suggesting next steps belonged in another skill I already had, so I moved it there. Now one skill finds what the research says, and the other helps me decide what to do with it.
How I write a skill
| My Approach |
My very first try taught me one thing: let Claude help you write the skill. It already knows a lot about how skills work, so why not use that?
I start a new chat and give Claude the context: what I’m working on, which task keeps repeating, the steps I keep asking for, and what I expect from the result. Then I ask Claude to:
fill in anything missing from my request
look for ways to improve it
keep it balanced: specific enough to give reliable results, but broad enough to work on similar projects
show me the sources it used
I learned the “balanced” part the hard way. At first, I wanted one skill for all my user research. But during my desk research, I realized user research is too broad for one skill. When a skill tries to do too much, it gets long, slow and general, and the results become unreliable. So I broke it down into smaller skills, and this one only handles interviews and focus groups.
I also keep each rule short and clear. For example, one line in my skill simply says: “Keep every quote word-for-word. Never paraphrase inside quotation marks.”
After that, it usually takes two or three rounds of testing. When I use the skill later in another project, I sometimes go back and refine it again.
Before, analyzing my interviews took me about three days. Most tools couldn’t understand Farsi, so I had to type out the transcripts by hand before I could even start. Now, preparing a report from my interviews takes two hours at most.
What I took from it
| Learning |
Writing skills taught me something about my own way of working. When I catch myself repeating the same thing, it usually means something needs a system. And just like in design, the first version is never the last one. I start small, test it, and come back to improve it when a new project shows me what’s missing.
Want to Contact?
I’d be happy to meet for a coffee or have a chat online.
