Why write a skill file instead of rewriting the same prompt?

You write a skill file instead of rewriting the same prompt because the prompt only asks for an output, and you end up rebuilding the work by hand every week. A skill file writes down the rules once: what the output includes, what it never includes, how the work is routed and where a person approves it. Then anyone can run it.

I stopped writing the same Claude Code prompts every week and wrote about it on my LinkedIn. This is the longer version.

Why stop rewriting the same prompt?

You stop rewriting the same prompt because a prompt you rebuild every week is a process you have not written down. Each time, you explain the job from scratch, the output comes back slightly different, and you fix the same things by hand. The work is still manual; the AI is just doing the typing.

Every week I was rebuilding the same things. Client reports. Meeting recaps. Task intake from transcripts into Monday. Each one started with me remembering what it should look like and typing that into a prompt again.

There is a second cost, too. When the rules live only in the prompt you happen to type that week, nobody else can run the job. The work is tied to one person and one memory, and it changes a little every time that memory slips.

So I stopped writing the output and started writing the rules. Now each process lives in a skill file in GitHub, and the same job comes out the same way every time, whoever runs it.

What goes in a skill file?

A skill file holds the rules of the job, not the answer to one instance of it. What the deliverable includes, and what it never includes. How tasks get scoped and routed, and who they can be assigned to. And where the approval step sits, so a person checks the work before anything goes out or changes.

Those last two are the ones people forget. A skill file that only describes the output will produce a good-looking draft and then do the wrong thing with it. Writing down who work can go to, and where a person has to approve it, is what makes it safe to hand the job over.

Keep the file in plain language. It is read by a tool, but it is maintained by people, and the next person to change it should be able to follow it without asking you what you meant.

A useful skill file usually covers:

• The deliverable, section by section, in the order it appears.
• What is never included, because exclusions are where most corrections come from.
• The routing rules: where each piece goes and who can own it.
• The approval step: what a person checks, and when.

How do you write the first one?

You write the first skill file by reverse-engineering a good example. Take a deliverable someone already does well, and write down every detail that makes it good, down to the formatting quirks. The quirks are the point. They are what people notice when the output is wrong and cannot explain when asked.

My first recap skill came from a teammate's meeting recaps. I wrote down how she formatted them: the section headings, action items grouped by owner, and the next meeting as a footer line. Every quirk that made the recap hers went into the file.

That is the part people skip. They want AI to do the work. The leverage is in describing the work precisely enough that it can. If you cannot say what good looks like, no tool will produce it reliably, and if you can, most tools will.

The transcript-to-task workflow is one of these files in action. Turning meeting transcripts into tasks shows what the routing and review rules look like when they run every day.

What do you get besides the output?

Besides the output, you get documentation you did not have before. Writing a skill file forces you to describe processes that were never written down. Most of my operating knowledge turned out to be living in my head and nowhere else, which is a risk for any team, and a skill file fixes it as a side effect.

That by-product may be worth more than the time saved. A process that lives in a file can be read by a new teammate, reviewed when something goes wrong, and improved by anyone. A process that lives in one person's head leaves when they are out, and the next person starts from scratch.

It is also why we build client systems the same way. Every rule a system runs on is written down where the client's team can read it, so the knowledge does not walk out of the door when we hand it over. That is part of what we do in GTM engineering, and how we hand a system over explains the rest.

What should you try first?

If you are building this internally, start with the deliverable you resent making the most, or the one that takes up most of your time. Find the best example of it you have.

Write down everything that makes that example good, what it never includes, where it goes and who checks it. Save that as a file, run it against next week's work, and fix the file, not the output, when something comes back wrong.