I developed a Skill that “eats” other Skills to upgrade itself — 饕餮.skill, now open-sourced for free

I had one Skill eat another. 10 minutes later, it had 4 new abilities.

Not manually copy-pasting, not comparing two SKILL.md files line by line. It’s AI analyzing the differences between two Skills, extracting advantage patterns, and reimplementing them using the target Skill’s own tech stack.

This Skill is called “饕餮.skill”. Today it’s free and open-source. Link at the end.

But this isn’t a user manual. What I want to talk about is: during the process of making 饕餮.skill, my understanding of “how to write a Skill” was completely transformed. Also, which design ideas I stole from projects like Voyager, TextGrad, and DSPy.

01

skills.sh has 90k installs, but most Skills stay at v1.

Let me set the stage.

The Skill ecosystem has exploded. Since skills.sh launched, cumulative installs have surpassed 90k, and Vercel’s official find-skills alone is nearing 800k. Microsoft has pushed a dozen Azure Skills in one go; Supabase, Expo, shadcn are all releasing.

Colleague.skill went open-source last week, got 8k stars in 5 days. Then Ex.skill, yourself-skill all came along — a whole distilled universe.

Skills have gone from “a niche geek toy” to “standard gear for AI developers”.

But have you noticed a problem? Most Skills, once released, just sit there.

v1.0 ships, gets a wave of stars, readme looks great. Then what? After a month you find it can’t handle some scenario, want to fix it but can’t be bothered. You see another Skill doing something better, want to integrate it, but don’t know how.

The real bottleneck in the Skill ecosystem isn’t “how to write a Skill” — it’s “how to make a Skill constantly evolve”.

Skill ecosystem explosion

02

Skills aren’t written — they’re cultivated.

Let me start with something I only realized after a long struggle.

Most people write a Skill with the mindset of “from zero to perfection” — spend three days writing a SKILL.md, covering every scenario, every edge case, then ship it. This approach has a fatal flaw: you can’t foresee every scenario.

My research skill is a textbook example. v1 took two days to write, covering a dozen platforms like Reddit, X, YouTube. Seemed complete. But after a month of real use, I found that Xiaohongshu scraping was broken — carousel images only grabbed the first page, comments data was half missing.

It wasn’t that v1 was poorly written. It’s that certain needs only surface in actual usage.

Later I saw a Xiaohongshu-specific summarizer skill on skills.sh that handled image-text carousel penetration beautifully. I wanted to integrate that capability into my research skill.

Manually doing it was excruciating. That Skill used Playwright, my stack was Chrome CDP — completely different tech stacks. I had to first understand why it used a certain Playwright API, figure out how to achieve the same effect with CDP, find the right insertion point in my SKILL.md, check for instruction conflicts, and then test.

By the time I finished, it was dark outside.

The result was great. But the process made me realize: the real growth path of a Skill isn’t “write it once” — it’s “continuously devour external advantages and evolve”.

03

Why merging Skills isn’t copy-paste

You might think merging two Skills is just moving the good parts over. I thought the same at first. Then reality taught me a lesson.

In practice, 80% of the time goes into three things.

The first pitfall is tech stack adaptation. Two Skills likely use different underlying implementations — one Playwright, one CDP; one Python, one TypeScript. You can’t just copy code. You have to understand what the other operation is trying to do, then reimplement it with your own tech stack. It’s essentially semantic-level translation.

The second pitfall is more subtle: context dependency. A strategy inside one Skill often works because it depends on other instructions in its context. Pluck it out and stuff it into another Skill, and it might completely fail — or even conflict with existing instructions.

I hit a case: the reference Skill had a rule “wait 3 seconds after each fetch before the next step”. I moved it straight over, and my research skill became painfully slow in concurrent mode — because my Skill already had its own throttling mechanism, and two waits stacked. You’d never catch this bug without running in a real scenario.

The third pitfall, and the most critical: what you move isn’t code — it’s patterns. What’s truly valuable is the design thinking behind the reference Skill — what are its design assumptions? Can this thinking be reimplemented in my way?

Every manual merge of a Skill takes at least half a day.

Pain points of merging Skills

04

The design philosophy of 饕餮.skill: three core ideas

Before building 饕餮.skill, I systematically studied three projects that do “AI self-evolution”: Voyager (Wang et al., Stanford+NVIDIA 2023), TextGrad (Yuksekgonul et al., 2024), and DSPy (Khattab et al., Stanford 2023). From their successes and failures, I distilled three iron rules.

Rule #1: Merge only at the strategy layer, not the implementation layer

Voyager’s early lesson — it dumped all learned skills indiscriminately into a library, causing interference between skills. The problem wasn’t too many skills, but failing to separate “what you want to do” from “how you do it”.

饕餮.skill’s approach: after ingesting two Skills, first extract the reference Skill’s strategic intent — what it’s doing, why it’s doing it, what its design assumptions are. Then reimplement those strategies using the target Skill’s existing tech stack. Move only the thinking, not the code.

Rule #2: Change only one dimension at a time

This comes from TextGrad and DSPy. If you change 5 things at once and the result gets worse, you have no idea which change broke it. DSPy’s MIPROv2 optimizer only tunes one module’s prompt at a time; TextGrad’s backpropagation updates one variable per step.

饕餮.skill’s injection strategy is also incremental. It prioritizes the multiple advantage patterns it has analyzed and injects them one by one. After each pattern is injected, it outputs a diff report, and you can accept or roll back.

This isn’t technical pedantry — it’s learned the hard way. In my early tests I injected 4 patterns at once, and two instructions ended up contradicting each other. Debug took forever.

Rule #3: Always create a backup before each injection

In machine learning there’s a term called catastrophic forgetting — the model forgets old knowledge when learning new things. Skills are the same.

I once injected a new ending strategy into my writer skill. Tested three posts, all fine. A week later I found that the original CTA template had stopped working — the new ending logic conflicted with the existing CTA instructions, and the new one overrode the old. By the time I found the problem, I’d already written several articles with the “crippled” version.

饕餮.skill automatically creates a .bak backup before every injection. Mess it up? One command to restore.

Three iron rules

05

How it works internally: Ingest → Align → Extract → Inject

饕餮.skill runs in four stages.

Step 1: Bidirectional ingest. Simultaneously read the full structure of both target and reference Skills — SKILL.md, scripts directory, references directory, all supporting files. Not just the surface docs, but the entire Skill directory tree.

Step 2: Capability alignment. Break down the capabilities of both Skills into modules and map them one-to-one. Which capabilities do I have that it doesn’t? Which does it have that I don’t? Which do we both have but it does better? Output a capability comparison table.

Step 3: Advantage pattern extraction. This is the most critical step. For each module where the reference Skill performs better, 饕餮.skill doesn’t copy its code — it extracts its “advantage pattern”: what strategy did it use? Why is this strategy effective in that scenario? What are its design assumptions?

Step 4: Progressive injection. Sort the extracted patterns by priority and inject them one by one into the target Skill. After each injection, generate a diff report containing: injection location, change content, design rationale, potential risks. You can approve or reject each item.

Four-stage pipeline

06

Real-world result: what the research skill looked like after eating

Enough theory. Let’s see what actually changed when my bggg-creator-research skill ate the Xiaohongshu summarizer skill.

Before eating: couldn’t scrape Xiaohongshu at all.

After eating: full deep-scrape coverage for Xiaohongshu — carousel penetration instructions, CDP extraction code templates, comment filtering rules, multimodal analysis pipeline. Existing modules for Reddit, X, YouTube remained completely unaffected.

What happened in between?

饕餮.skill analyzed and found 4 core advantages in the reference Skill: image-text carousel penetration (simulating real swipe navigation), multimodal content extraction (image OCR + video frame sampling), topic-based synthesis (reorganizing information by theme rather than listing posts), and comment spam filtering (filtering marketing accounts and bot comments).

The key was tech stack adaptation. The reference Skill depended on playwright-cli; my research skill’s foundation was Chrome CDP. 饕餮.skill didn’t introduce Playwright — it reimplemented everything using existing CDP capabilities: clickAt (real mouse event simulation) replaced Playwright’s click logic, CDP’s Tab key navigation replaced selector-based positioning. Zero new dependencies, full strategy migration.

SKILL.md went from v1.0 to v1.1. The whole thing took 10 minutes. Last time I did it manually, it took most of a day.

Before/After comparison

I later used 饕餮.skill to strengthen my writer skill (ate a vertical-business blogger’s writing style system, added paragraph rhythm control) and my illustrator skill (ate baoyu-cover-image’s five-dimension prompt design, added color scheme and composition rules).

07

Things it can’t do

Honestly, there are two scenarios where 饕餮.skill doesn’t handle well.

First, if the two Skills have vastly different programming languages (one Python, one TypeScript), 饕餮.skill can only extract strategic suggestions — it can’t automatically rewrite code. It can modify instructions in SKILL.md, but code in the scripts directory needs your own hands.

Second, if the reference Skill is poorly written — no structure, no comments, messy logic — the quality of 饕餮.skill’s analysis will suffer. Garbage in, garbage out. A SKILL.md without a clear structure won’t yield valuable patterns even if you feed it to an AI.

Third, 饕餮.skill can’t do fundamental cross-architecture refactoring. If the underlying design philosophies of the two Skills are completely opposite — one is a serial pipeline, the other a parallel agent network — 饕餮.skill can only optimize at the local module level. It can’t make architectural-level decisions for you. That still requires your own judgment.

08

Open-source address

GitHub: https://github.com/binggandata/bggg-skill-taotie

Installation: place the 饕餮.skill directory under ~/.claude/skills/ or ~/.agents/skills/.

Usage: in Claude Code, say:

Feed [reference skill] into [target skill] to optimize [a specific capability]

Or you can omit the direction — 饕餮.skill will run a full comparison on its own, tell you how many advantage patterns the reference Skill has worth learning, and you choose whether to inject.

09

From “writing Skills” to “cultivating Skills”

After building 饕餮.skill, my entire approach to Skill development changed.

Before, I pursued “write a perfect Skill from scratch”. Not anymore — first quickly write a 60-point version, then continuously find good reference Skills to feed to 饕餮.skill for evolution. Each evolution preserves version history, so you can see what v1 ate and what v5 added.

You don’t need to figure everything out at the start. You just need to build a mechanism for continuous evolution.

Now there are hundreds of Skills on skills.sh. Most people treat it as a download marketplace — find one that works, install it, and if it’s bad, switch to the next. But try another perspective: those hundreds of Skills aren’t finished products — they’re raw materials. Your own Skill is the finished product. Other people’s Skills contain parts you need. Use 饕餮.skill to disassemble those parts and assemble them onto your own Skill.

Your time shouldn’t be spent manually deconstructing someone else’s code. It should be spent deciding “what to feed”. Choosing what to eat is more important than how to eat.

If you found this useful, drop a star on GitHub. Tell me in the comments: what capability is your current Skill most lacking? Who do you want it to “eat”? I’ll pick a few good scenarios and turn them into case studies.