A few days ago I saw a post saying GitHub is becoming Xiaohongshu (China's Instagram-like lifestyle app). The more I thought about it, the more sense it made.
Casual Participation
At the end of March, the Claude Code source code leaked. It wasn't an intentional open-source release—a 59.8 MB source map shipped inside the npm package, and following it led to the complete source code on Anthropic's storage bucket: nearly 1,900 TypeScript files, 510,000 lines of code. Bun generates source maps by default, and nobody added it to .npmignore. So it leaked.
After the leak, a bunch of open-source projects popped up. One of them is OpenClaw, formerly called Clawdbot, renamed due to an Anthropic trademark complaint. It supports various LLMs and now has 350,000 stars.
I had wanted to hack Claude Code to support OpenAI models. Codex isn't as good as Claude Code at information organization and task orchestration, but I gave up after assessing the workload. When I saw OpenClaw, I thought: as expected, if you can think of it, someone has basically already done it.
I downloaded it and tried it out. It worked, but the reasoning effort defaults to high, whereas I usually use extra high. Used alongside Claude Code, xh can indeed tackle more complex problems. But there was no way to change it.
So I got to work. I had Claude Code help me modify OpenClaw's code, adding a three-tier provider → model → effort structure, similar to the multi-API architecture approach seen in Open Code and Kilo Code. After fixing some bugs, I casually submitted a PR.
CI failed; I ignored it. A colleague tried it and said fast mode didn't work. Indeed, xh is too slow for daily use, so I usually run fast mode. I made another round of changes and added them to the PR. CI failed again—the smoke tests wouldn't pass.
The original author replied with one word: conflict.
Understandable. Changing from a fixed three-model design to multi-provider, multi-API was too big of a change. It conflicted with the direction he wanted to maintain.
But the whole process was quite interesting. See it, download it, tweak it if it doesn't feel right, submit a PR with one click. The other person's comment arrives via email; you glance at it and reply. It's basically like scrolling through Xiaohongshu. Gone is the ceremonial sense of "formally contributing to an open-source project"—you just do it when you see it.
The Dumpling Shop's Skill
Around the same time, I saw another post.
Jingu Yuan Dumpling Shop, a restaurant next to Beijing University of Posts and Telecommunications (BUPT), had its owner make a Claude Code skill and publish it on a WeChat Official Account.
The content was a bit funny: the menu, delivery info, Wi-Fi password—all packed in. The owner said you could use this skill at the shop to get the latest information.
The funniest part was the comments under the official account post. A bunch of people were filing issues for the dumpling shop.
WeChat Official Accounts have become GitHub-ified.
The owner said that because the shop is next to BUPT, customers come in every day talking about AI, skills, and Claude Code. After hearing enough, he went home and vibe-coded it in a few hours.
The skill itself isn't very useful. Who would install a skill just to check a dumpling shop's Wi-Fi password? But if the dumpling-making process were included, like how Laoxiangji (Country Style Chicken) once published recipes—glancing at the steps while cooking, letting it recommend ingredient pairings—that would actually be pretty interesting.
Hollywood's GitHub
Not long ago, I was having dinner with someone and asked if they had seen Resident Evil. The lead actress, Milla Jovovich, who also starred in The Fifth Element, published a project under her own GitHub account in early April.
The project is called MemPalace, an AI memory system. Inspired by the method of loci (memory palace technique), conversation data is organized into a three-tier structure of wing, hall, and room. It stores raw conversations rather than summaries, runs locally with ChromaDB and SQLite, and costs zero API fees.
The motivation was straightforward: when using AI chat, she found existing memory systems arbitrarily deciding what to remember and what to forget. She couldn't stand it, so she pulled in a crypto developer named Ben Sigman, and the two of them built it over several months using Claude Code.
It hit over 20,000 stars in two days and now has more than 40,000. The controversial part was the benchmark. The project initially claimed a perfect 100% on LongMemEval, but was later suspected of having test-specific optimizations, and the score was revised to 96.6%. Still, the architecture itself received positive reviews, including feedback from a computer science professor at USC.
A Hollywood star, GitHub repo owner, 40,000 stars. A few years ago, nobody would have believed this.
Distilling Colleagues
A phrase has started trending on WeChat Moments: distill your colleague into a skill.
Someone actually did it. A project called colleague.skill hit 70,000 stars within days of launching. It feeds in a colleague's Lark messages, DingTalk documents, and work emails to generate an AI skill that mimics that person's work habits and decision-making style.
Derivative projects keep popping up. Distilling exes, distilling oneself, distilling public figures. The most extreme is an "anti-distillation" tool that generates a skill file that looks complete but deliberately hides core knowledge, to prevent oneself from being distilled.
I think people are overthinking this.
Most people's so-called personal style at work isn't worth much. Communication habits, ways of interacting—you'll find they don't actually create anything when you really use them. The effect of these personalities isn't even as significant as the differences between the models themselves. Pairing different models with different skills is probably far more useful than distilling a person.
The mental image is thrilling: pour in the chat logs, and the person can be replaced. Cue anxiety. But like the dumpling shop's Wi-Fi password, there's simply no real demand for this.
Skills Aren't It, Agents Are
The dumpling shop owner did say something interesting: the future might be location-based. Your personal assistant agent walks into the shop and interacts directly with the shop's agent.
I think this direction is right.
You bring your own agent. It knows your taste, what you've eaten recently, what you're allergic to. You walk into a restaurant, and your agent chats with the restaurant's agent: What's on the menu? What's recommended today? Which dish has good reviews? After the conversation, it makes a recommendation based on your preferences. You only need to talk to your own agent.
This isn't the same as scanning a QR code. When you scan a code, you're the one facing a bunch of dish names and ratings, looking and choosing for yourself. Agent-to-agent connection is two programs that know their respective owners, communicating on your behalf.
If a restaurant distills its experience, dish knowledge, and customer feedback into its own agent service, your agent connects with it, gets everything it needs to know, and you just make the final call. This is completely different from the old days of scanning a QR code to order.
The problem with skills is that they're still stuck at "humans actively install and use them." A Wi-Fi password skill? Nobody installs that. But if the shop becomes an agent service, you walk in and it automatically connects.
Where Did the Barriers Go?
A restaurant owner vibe-codes a skill in a few hours. A Hollywood star is the first author on a GitHub repo. A 350,000-star alternative pops up days after a source code leak. My entire PR process felt as casual as posting a Xiaohongshu note.
In the past, "contributing to open source" meant reading docs, reading code, writing tests. Now you see it, you change it, you submit it. GitHub is becoming Xiaohongshu-fied, and official accounts are becoming GitHub-fied. The barriers are indeed disappearing.
As for agent interoperability, looking at the pace of projects like OpenClaw, it may be closer than most people think.