There is a saying that when a trip is over, what remains is the photos. After working with AI for a while, my experience tells me: what remains is the skill. Indeed, letting go of heavy prompts has opened up new possibilities for me, proving why reusable "Skills" are the real game-changer for AI productivity."
Overview
Using AI tools at work is no longer a choice but a necessity, and it has been that way for some time.
Having used Claude steadily in real-world work, I would like to share an experience where an approach different from the widely promoted one led to better results.
This is the story of a journey that started with asking simple questions instead of preparing elaborate prompts, and ended with turning repeated work into Skills that multiplied my productivity several times over.
I will walk through this journey using a real case from a recent knowledge base project I have been working on.
Two Ways of Approaching Prompts
As AI tools like Claude spread, I remember a period when interest in prompt-writing techniques ran very high.
Advice overflowed in every community: assign a persona, provide plenty of context, lay out a step-by-step plan first, and specify the output format in detail.
It was a time when a prompt longer than a full page was treated as a measure of dedication.
To borrow a cooking analogy, it was like buying measuring tools and equipment and binge-watching recipe videos before ever starting to cook.
I did not go along with that trend.
Instead of spending time on preparation, I kept to a way of working where I simply asked for what I needed, right away.
I chose to turn on the stove first and start cooking.
Ask Simply, Then Choose: How the Knowledge Base Project Began
Recently I started a project to build a personal knowledge base.
Following the fashionable method of the time, I would have had to prepare a prompt like this:
You are a technical documentation expert with 10 years of experience.
Compare static site generators (SSGs) and propose a knowledge base plan.
Evaluation criteria:
1. Build performance 2. Plugin ecosystem 3. Markdown compatibility ...
Output format: comparison table + pros and cons + final recommendation ...I started with this instead:
I want to build a knowledge base. How should I get started?Among the several directions Claude suggested, I chose Docusaurus and began building.
Up to that point, it was an ordinary process. The real experience came afterward.
As I continued the build, asking simple questions whenever something came up, I came across an alternative in the middle of a conversation: Hugo.
It was an option that had never been in the original plan.
I judged that Hugo was a better fit for my situation and requirements, and as a result, the knowledge base changed direction and moved onto Hugo.
Looking back, if I had locked in a "Docusaurus-based knowledge base construction plan" with an elaborate prompt from the start, I would never have had the chance to meet Hugo.
This gave me an insight: crafting a highly detailed prompt can end up narrowing, in advance, the space from which answers can emerge.
It seems to work the same way as a recipe fixed to the gram — failures decrease, but so do the chances of a happy accident from trying a new ingredient.
The division of roles — Claude spreading out the possibilities wide, and the user judging and choosing — brought me not only better results but also serendipity, in a way that control-oriented long prompts had not.
Lately I have been confirming that this experience is not mine alone.
As models have become better at inferring context on their own, it appears that more and more people are sharing the same realization: you do not need to pack everything into the prompt.
💡 Key takeaway: An elaborate prompt can narrow the answer space in advance. Asking simply, receiving broadly, and then choosing is what made the serendipitous path from Docusaurus to Hugo possible.
Noticing Repetition, and Then Skills
As the knowledge base work went on, a pattern started to catch my eye.
Every time I registered a document, I was repeating similar requests.
Match the front matter format, place the file according to the folder classification rules, follow the document template structure, keep internal link notation consistent — I was saying these over again, every single time.
The results of each conversation were excellent, but when the conversation ended, the know-how refined inside it evaporated along with it.
When registering the next document, I had to explain everything from the beginning again.
In cooking terms, it was like making the same dish for the third time while still reciting the steps from scratch every time.
If you have repeated something three times, it has already earned the right to become a recipe. All that remains is to write it down.
Claude's Skills are exactly that act of writing it down.
Put the know-how of a repeated task into a single folder, and Claude will reference it on its own whenever it encounters related work, and carry it out accordingly.
The structure is simpler than you might expect. The core is a single SKILL.md file.
---
name: kb-doc-standard
description: Use for knowledge base document registration/conversion.
Triggered by requests like "add this to the knowledge base"
or "clean up this document."
---
# Knowledge Base Document Standard
## Principles
- Write front matter in the order: title, date, tags, category
- Place documents according to the folder classification rules
- Follow the document template structure (overview - body - references)
- Use relative paths consistently for internal linksThe implicit know-how I used to repeat out loud — "like last time, you know how" — was now formalized into a reusable form.
There is one point I want to emphasize here.
Skills do not conflict with the simple-prompt approach; rather, they complete it.
A long prompt is a cost you pay again every time, while a skill, once written down, becomes an asset that does not disappear.
And because the skill takes charge of format and procedure, prompts actually become even shorter.
Now I can just say "let's add this document to the knowledge base," and everything from front matter to folder placement proceeds on its own.
💡 Key takeaway: Know-how inside a conversation disappears when the session ends. I recommend formalizing any pattern repeated three or more times into a skill. When the skill handles the format, the prompt becomes even simpler.
Tools May Change, but Skills Remain
I experienced that the true value of skills reveals itself not at the moment of creation, but at a project's turning point.
As introduced earlier, the knowledge base changed direction from Docusaurus to Hugo.
It is easy to assume that when you switch tools, you also have to throw away the working methods you have built up.
In practice, that was not the case.
The skills created during the build — the document standard, the folder classification rules, the conversion procedures — were reused almost as they were, even after the tool changed.
Only the tool-dependent parts, such as the fine details of the front matter format, needed a few lines of editing.
It works on the same principle as a recipe: if you have one, you can make the same dish even when the kitchen changes.
Afterward, whenever I started other documentation work of a similar nature, these skills served as leverage.
The changes I felt can be summarized as follows.
| Aspect | Heavy prompts | Simple prompts | Simple prompts + Skills |
|---|---|---|---|
| Cost to start a task | 20–30 min writing the prompt | Immediate | Immediate |
| Diversity of results | Low (within what I imagined) | High (serendipity) | High |
| Quality consistency | High but rigid | Varies per conversation | High and flexible |
| Know-how accumulation | Scattered across prompt docs | Lost when the session ends | Permanently accumulated as skills |
| Switching tools/projects | Copy, then heavily rewrite | Explain from scratch again | Reused almost as-is |
| Productivity on repeated work | Baseline | Improved | Several times higher, in my experience |
I consider the last two rows to be the heart of it.
Productivity multiplied not because the AI suddenly became smarter, but because I no longer had to give the same explanation again.
It reconfirmed for me that the greatest waste in knowledge work is not the work you cannot do, but redoing work you have already done as if it were the first time.
There is a saying among office workers: you may leave the company, but the skills you have built stay with you.
I would say this experience was a case of that saying being realized quite literally.
Docusaurus is gone, but the skills built on top of it remain — still working, now in Hugo.
💡 Key takeaway: Even when the tool changes, the skills survive. The secret to higher productivity is not a smarter AI, but a structure in which the same explanation is never repeated.
Try It in Your Own Work
So far I have shared a hands-on journey that started with simple prompts and led to making the most of Skills.
The journey came down to three stages.
First, instead of spending time on preparation, ask simply and choose among the directions Claude presents. Just as a project that started with Docusaurus met a better option in Hugo, this is where you encounter serendipity.
Second, notice the repetition. If you are making the same request three or more times, it has earned the right to become a skill.
Third, reuse and adapt the skills you have made — across tool changes and across similar projects. Prompts get shorter and shorter, while the quality of the output stays consistent.
This is not to say that the effort of carefully writing heavy prompts was wrong.
The point is that this dedication should be directed not at prompts that are consumed and gone each time, but at skills that, once written, remain.
If there is work you find yourself repeating, I recommend building at least one skill for it.
It can raise your productivity more than you might expect, and I anticipate it will be an opportunity to upgrade your AI experience to the next level.
When a trip ends, the photos remain. When a conversation ends, the skill remains.
What remains is the skill.
