Last week a project called "Colleague.skill" popped up on GitHub. It broke 1,000 stars in three days and now sits at more than 5,000.

The slogan is surprisingly tender: "Turn the coldness of parting into a warm Skill. Welcome to Digital Life 1.0."

The mechanics are simple, too: feed in a departing colleague's Feishu messages, DingTalk docs, emails, and screenshots, and the AI generates a Skill file that can do their job — write code following their technical conventions, answer questions in their tone, and even know when they tend to shift the blame.

But this article isn't here for the jokes. As someone who writes Skills and uses Skills every day, I want to seriously unpack what this thing is actually doing, and how you can put it to proper use.

Its Technical Architecture: One Person Split into Two APIs

The technical implementation of Colleague.skill isn't complicated, but the architecture design is clever. It splits a person into two layers:

# SKILL.md
layer_1: Work Skill
# Technical conventions, decision paths, coding habits
# This is what he "can do"

layer_2: Persona
# Way of speaking, communication rhythm, emotional reactions
# This is how he "does it"

The execution flow is: Task -> Persona sets the attitude -> Work Skill executes -> Output

Supported data sources include Feishu, DingTalk, and Slack messages, email, PDF documents, and even screenshots. You can also skip uploading anything and generate a Skill purely from a text description, though the precision will be somewhat lower.

It also supports version management — if the AI's answers don't sound enough like the real person, you can just say "he's not that gentle; he usually fires off a question mark first," and the system writes it into a Correction layer so the next conversation gets corrected.

The Skill Universe Has Exploded

After Colleague.skill took off, an entire ecosystem sprang up on GitHub within days:

• Ex.skill: distills chat history into an AI ex. The delete command is /let-go; listing all your exes is /list-exes. Even letting go gets written as an API.
• Yourself.skill: its slogan is "rather than distilling others, distill yourself." Create a digital twin that's online 24/7.
• Boss.skill: abstracts your boss's management style into an Agent that helps you manage up.
• Anti-distill.skill: being asked by your company to hand over your Skill file? It generates a version that looks complete but has the core knowledge removed. The worker's way of holding something back in the digital age.

Related links:

• Colleague.skill: https://github.com/titanwings/colleague-skill
• Ex.skill: https://github.com/titanwings/ex-skill
• Mentor.skill: https://github.com/ybq22/supervisor
• Anti-distill.skill: https://github.com/leilei9265-tech/anti-distill

Three Attitudes: Passive Distillation, Fake Distillation, Active Distillation

Faced with the trend of turning work into Skills, there are three strategies:

Only the third is the right path.

Hua Shu started writing his writing style, judgment criteria, and workflows into Claude Code Skills a year ago. He now runs dozens of Skills: one for topic selection, one for research, one for writing, one for editing, one for illustration — even publishing to Feishu has its own Skill.

There is only one difference: who controls the distillation process.

Key Insight: Skill-ification Can Kill Repetition, but It Can't Kill Iteration

If your job is a fixed process, fixed standards, and fixed output, then yes, it can genuinely be replaced by a good-enough Skill.

But think about it: if distillation were really this effective, why has nobody tried to distill Elon Musk? All of Karpathy's public talks, papers, and tweets are online. The biographies, shareholder letters, and interviews of Charlie Munger and Warren Buffett add up to tens of millions of words. But if you generated a Musk.skill from all that, could it help you build the next SpaceX?

It can't. Because what makes these people truly valuable is how they respond to the unknown. That kind of thing isn't in the text.

So the strategy that actually works is:

Turning your own workflow into Skills is precisely the approach least likely to be replaced by a Skill. You hand the repetitive parts over to Skills and free up your own hands to think about new things. You always stay ahead of your own Skills.

Meanwhile, the people who never organize or refine anything are actually in more danger — their repetition and their creativity are mixed together, and if someone distills them from chat logs, the result might genuinely sound a lot like them.

Practical Advice

If you want to start actively distilling yourself, begin with these steps:

1. Map out the repetitive processes in your work: which standardized operations do you perform every day or every week? These are the top priority for Skill-ification.
2. Use Claude Code to create your first Skill: write one complete workflow as a SKILL.md, covering goals, steps, and judgment criteria.
3. Keep iterating: a Skill isn't something you write once and you're done. Every time you find a way it could do better, update it.
4. Focus on the core question: the part of you that won't fit into your SKILL.md is your real moat.

"Know thyself" used to be carved into the Temple of Delphi — a question of philosophy. Now it has become an engineering question: what should go into your SKILL.md? More importantly, which things can't you write into it?

The part you can't write down is the part that's really you.