How to Create a Skill in Claude Cowork in Under 5 Minutes

A skill is a repeatable routine Claude runs without you explicitly calling it: it recognizes from your message that the routine applies and pulls it up. Creating one takes any task description as raw material, a tweet is enough, and under five minutes. The whole flow is: enable the Skill Creator, paste the text, answer a short interview, add the result to your library. Here it is step by step, with the two caveats that matter.

How do you create a skill in Claude Cowork?

My raw material was a tweet by Danny Postma describing an interviewing workflow. Any text describing a task you repeat works the same way.

1. In Cowork, check the skill capabilities section and turn on the Skill Creator if it is not already on. It is itself just a skill whose job is making other skills.
2. Open a new task, paste your text, and say "make this a skill." You do not invoke the Skill Creator by name; skills are picked up from whatever you send, and it detects that this is skill-making work.
3. Answer the interview. The creator asks scoping questions: should this interviewer be narrowed to software product specs or stay general? Who decides when the interview is done, you or it? What output format, markdown? Answer the ones you care about and skip the rest to keep the skill broad.
4. It writes the skill file, packages it for distribution, and walks through verification with you.
5. Review the generated markdown, then add it to your library. Done; the next session can use it.

The file at the center is skill.md. Its description field is the trigger: Claude reads it to decide when a message means "run this skill." Skills can also package scripts, Python included, which is where they get real power beyond prompts.

Skills vs slash commands

Honest note on my example: an interviewer prompt is probably better as a slash command, something you invoke deliberately, than a skill that fires on inference. But slash commands are loaded as skills under the hood now anyway, so the distinction has collapsed into details. If you are non-technical, treat them as the same thing and do not spend energy on the difference.

The two caveats

Every enabled skill costs context. Skills are auto-discoverable, which means each active one injects tokens so Claude knows when to call it. Do not leave your whole library switched on; toggle skills off when a project does not need them. This is a measurable performance issue; it is one of the ways context rot sneaks in.

Name your skills distinctly. Saying the skill's name in a message is the most reliable trigger. Inference works well when your active set is small, but two skills with similar names will confuse the routing. Distinct names, small active set, no trouble.

The natural next step once a skill proves itself: wire it to a scheduled task so it runs every morning without you. That pipeline, workflow to skill to schedule, is how one-off experiments become automation. For finding workflows worth converting in the first place, start with the low-stakes experimentation loop.