Your team has started giving its AI agents written instructions: how you review code, how you name things, what good UI motion looks like in your product. Meanwhile someone has published a far better version of half of that, for free, with thousands of stars. The question every team hits is whether to write its own from scratch or install theirs. Both answers are wrong.
Writing from scratch throws away work that people with more taste than your team already did. Installing wholesale gives you a second rulebook sitting next to your first one, and neither the agent nor anyone on the team can see where the two disagree.
What I did instead
In July I looked at emilkowalski/skills: eight skills, about 2,260 lines of pure markdown, MIT licensed, with 21,737 stars on the GitHub page the day I read it (28 July). It encodes one design engineer's taste in UI motion as a list of specific mistakes agents make, such as ease-in on an entrance or a solid border where a soft shadow belongs.
My own motion rules were one 103-line file, and grep -c spring on it returned 0. The gap was real. Instead of installing the pack as a ninth design skill, I had a model read it, deduplicate it, and lift what was missing into files I already had, as edits. It landed as 3 reference files, 2 grafts and 1 spec, and no new skill.
The side effect that justified it
Because the import landed as edits to my existing rules, the model had to put old and new next to each other. That surfaced two contradictions I did not know I had.
ease-inon exits. My old rule prescribed it. The imported rule bansease-inon UI in both directions, because it delays the moment the user is watching. I adopted the imported rule.- Delete first, or downgrade first? My audit skill said to prefer downgrading an animation over removing it. The import says delete first. On inspection they answer different questions: mine is a performance remedy, theirs is about whether the motion earned its place. Both stayed, each routed to its own question, and the conflict is written down in the file.
Installed as a separate skill, both contradictions would have stayed invisible. The agent would have picked whichever rule it happened to load, and nobody would have known why its behaviour changed from one day to the next.
How to run an import like this
For a team adopting any public skill pack, the steps are short:
- Map before you merge. Ask the model which of your existing files each upstream rule belongs in. A rule with no home is a candidate for a new file, not a new skill.
- Ask for a conflict list, not a summary. The useful output is every place the upstream rule and yours disagree, quoted side by side.
- Resolve each conflict by the question it answers. Two rules that look opposed often answer different questions. Write that routing into the file so the next reader sees it.
- Record where each rule came from. When upstream changes, you want to find the lifted lines without rereading everything.
Why a model should do the copying
This is work a model does well and a person does badly: reading 2,260 lines, spotting that two files say the same thing, mapping each rule to the file where it belongs. What the model should not do is decide the conflicts. It should surface them, and a person picks.
The rule I apply now, and would give any team adopting public skills: an external skill pack lands as edits to the skills you already have, never as a new one beside them. Ask the model for the diff, read the contradictions it finds, and decide those yourself. If a lift of any size turns up zero contradictions, be suspicious of the lift, not proud of your rules.
Strip the marketing too. That repo's main skill names the author's course before doing any work. The taste is worth copying. The funnel is not yours.