AI Guides › Skills & Agents
Sharing A Skill With Your Team Without Sharing Your Bad Habits
By Nigel Guy · 3 min read
A skill you built for yourself carries all your personal shortcuts baked in quietly — the exception you always make, the check you skip because you already know the answer, the assumption that's true for your specific accounts but nobody else's. It works for you because you unconsciously compensate for its gaps. Hand it to a team, and the gaps stop being invisible; they become everyone else's problem.
The rule: a skill built for one person and a skill built for a team are different documents — sharing yours as-is usually means sharing your blind spots along with your shortcuts, and that needs a deliberate rewrite pass, not a copy-paste.
The mechanism
- Find the places you personally compensate without noticing. Read through your skill and ask, at each step, "would this still be correct if someone without my specific context ran it?" The steps where you'd answer "well, I'd know to adjust that" are exactly the ones that need to become explicit instructions instead of tacit knowledge.
- Replace personal shortcuts with stated rules. If you skip a check because you already trust the source, write the check back in for the shared version — the next person running this skill doesn't have your trust built up, and shouldn't have to take it on faith either.
- Widen the guardrails to cover people who aren't you. Your guardrails section, written for solo use, probably assumes you'll catch certain mistakes because you know your own domain. A shared version needs to say plainly what a first-time user might get wrong, not what you specifically might get wrong.
- Remove assumptions specific to your setup. Account names, folder structures, tools only you have access to — anything hardcoded to your environment needs to become a stated precondition ("requires access to X") rather than a silent assumption baked into the steps.
- Have an actual colleague run it before it goes to the whole team. Not you reading it and imagining someone else using it — someone who wasn't involved in writing it, actually following the steps. The gap between what you assumed was obvious and what's actually clear only shows up this way.
What to skip
Skip sharing a skill "as a starting point, they can fix it up" if you know it has habits baked in that only work because of context you have and they don't — that just relocates the debugging cost onto someone with less information than you had. And skip assuming a skill that's worked well for you personally will work the same way at team scale; team use surfaces edge cases solo use never hits.
Guardrails
- This rewrite pass takes real time, and it's tempting to skip when the deadline is "just send it to the team already" — but a skill that quietly produces wrong output for a colleague costs more collective time than the rewrite would have.
- Once shared, a skill picks up the maintenance tax of everyone who uses it, not just you — changes to it now need communicating, not just personally remembering.
- Sharing doesn't make a skill more trustworthy by default — if anything, a team-shared skill deserves more scrutiny before adoption than a personal one, precisely because more people will act on its output without having written it themselves.
All 751 AI guides · JulieMango plans from £17/mo