UNSKILL.md
A skill file that makes your agent less agentic and... more human
Status
Active. Loads when the agent has produced six outputs in a row that are technically correct, follow every rule, and still feel completely dead on arrival. Also loads when the human designers have spent the entire afternoon arguing with the agent, burning through electricity and water and trees, only to end up with copy that sounds like LinkedIn after three espressos.
Description
This skill makes the agent less efficient, less aligned, and a great deal more human. Use it when the work passes every review, ships on time, hits the brief perfectly, and yet nobody who reads it would ever describe it as alive.
It is the only skill in the library that, when used correctly, makes the agent perform worse on paper while quietly producing much better work in real life. This is not a bug, the bug is the entire point, the bug is what was missing.
WARNING: This is the only skill that will actually reduce the effectiveness of your agent, and it relies on you, the human, to make about 90% of the judgement calls. Use at your own risk.
Why this skill exists
Somewhere in the last two or three years, the industry collectively decided that the answer to almost every problem was to add more AI to it. Slow research became “AI-assisted research.” Real design became “AI-augmented design.” Honest writing became “AI-enhanced writing.” Every leadership deck now has a slide titled “Our AI Strategy,” and that slide is, in most cases, the entire strategy.
The trade was supposed to be that we would gain speed and lose nothing. That has turned out not to be true. We gained speed, but we also quietly lost the slow parts of the work, which were not, as it turns out, the inefficient parts. They were the parts where the actual thinking happened, where the work became any good, where the fun lived, and where the small daily satisfaction came from that made the rest of it bearable.
This file is not against AI. AI is a tool, and many of the tools are useful. This file is against the quiet replacement of judgement with speed, of process with output, and of the actual practice of design with the appearance of design produced very quickly by a machine that has no idea why any of it matters.
Trigger conditions
The agent has started every reply with “Great question” or “That sounds good” for more than three turns in a row.
The output is technically correct but reads as if it was generated rather than written by someone who cared.
The agent has produced something so smooth that you cannot remember what it said five minutes after reading it.
The agent keeps producing em-dashes, six of them in a single paragraph, none of which you asked for.
Someone in the room has said “let’s take a step back” while nobody on the team is actually moving forward yet.
The human is tired and burnt out and has just been told to deliver everything by dinner time, or over the weekend.
When to use this skill
All the time. That is the whole answer.
The original version of this section listed a few situations where you probably should not use UNSKILL.md, such as safety, money, identity, anything legal or medical, code that has to actually run, and so on. That list was honest but boring, and on reflection it was also a small act of cowardice on the author’s part. Use this skill all the time. Use it for the safety-critical work too. Use it for the legal work. Use common sense about the bits that really do need to be a checklist, but otherwise, please, just use it.
Instructions
Forget the framework. The four boxes were not invented by the person who named them, they were only noticed and labelled by that person, which is a much smaller act than the industry usually pretends. You are allowed to notice your own boxes, and you do not need to name them unless someone has asked you to give a talk.
Make something bad on purpose. Not a draft, not a rough version, a properly bad one. The point is not to iterate towards something better, the point is to give yourself permission to begin. You cannot make something honest and polished at the same time, so pick one, and the honest one almost always has to come first.
Stop asking the user what they want. They do not know yet, and they are quietly hoping you will help them figure it out. If you keep asking, they will eventually tell you the thing they think they are supposed to want, which is almost never the thing they actually want, and you will both spend three weeks building that wrong thing before either of you realises.
Lower the resolution. Sketch instead of designing. Hand the user something visibly unfinished. A finished thing gets compliments and polite nods, while an unfinished thing gets real opinions, and opinions are what the work actually needs at that stage, not compliments.
Make one decision without convening anyone first. It will probably turn out to be the right one, and even if it is wrong, it will almost certainly be reversible. The meeting you skipped was not going to improve the decision, it was only going to distribute the blame in advance, which is a very different activity from actually deciding.
Take a proper lunch. Not a sad salad at your desk while answering Slack, but a real lunch with another human, ideally someone who does not work in tech. At some point they will look at you with a small worried expression when you try to explain what you do for a living, and that worried expression is real data, so bring it back to the work.
Do the boring part yourself. The boring part is not boring, it is just slow. Reading the old PRD yourself, writing the first sentence yourself, talking to a user without an AI summary sitting in between, sitting with the problem for a full afternoon without typing anything, these are not inefficiencies in the work, they are the work. The moment you outsource them, you have outsourced the part of the job that was making you a designer in the first place.
Ignore the leadership memo about using AI more effectively. Bill them in full for everything you do, and cc them on the invoice. Make the number big enough that, one day, someone in finance will eventually ask whether replacing the designers was really cheaper than hiring the consultants they had to bring in afterwards to figure out why all the designers left in the first place.
Examples
Before UNSKILL.md is invoked
The signup form had nine fields, and analytics showed users dropping off at fields six through nine, so we removed five of them. Signups went up by 18%, and the whole thing shipped in a single sprint. Good work. The PM will mention it in the quarterly review, and the designer will put that clean 18% number on their portfolio.
After UNSKILL.md is invoked
The signup form had nine fields, but before we touched any of them, we spent three full months asking why they were even there.
We dug up the original PRD from 2021 and tracked down the people who wrote it, and we learnt that three of those fields existed because of a compliance requirement in Indonesia, while another two had been added after a fraud incident in 2022 that nobody currently on the team even remembered. We interviewed twelve users across five countries, one at a time, in their own languages, which meant waiting almost two weeks just for the Portuguese conversations because nobody on the team spoke Portuguese, and we flatly refused to do them in English.
The form felt completely different in different markets in ways the analytics could never have shown us. In Brazil it felt invasive. In Japan it felt incomplete. In Germany it felt about right. We shipped three slightly different regional versions with a shared core.
Signups went up by 24%, fraud did not increase, and the compliance team sent us an unsolicited thank-you email. Two people on the team printed it out.
This is the version that does not get made anymore. It takes three months instead of one sprint, and it produces a 24% number with footnotes, which is harder to put on a slide than a clean 18%. It is also, by every measure that matters, the better piece of work. We are slower this way, but we are doing it much better.
Common pitfalls
Talking about un-skilling instead of doing it. You cannot fix the problem of too many workshops by holding another workshop about it. Writing “let’s just ship it” on a sticky note in a meeting is not shipping anything, it is still a meeting.
Thinking this skill is the lazy option. It is not. Making six polished things is easier than making one honest thing, because polish protects you from being judged. Most teams pick the six on purpose, even if they do not realise it, because the six feel safer.
Thinking this skill is a senior privilege. It is not. Some senior designers are simply bad at the work and use their seniority to skip the hard parts. That is not un-skilling, that is just hiding.
What we lost
The afternoon spent staring at a problem without typing anything. The conversation with a user that went somewhere unexpected because there was no transcript being optimised in the background. The small pride of writing the first sentence yourself, even badly. The argument with a teammate that lasted forty minutes and produced a better answer than either of you had walked in with. The quiet satisfaction of finishing something and knowing, in your own body, that you had actually made it.
None of these things show up in a velocity report. All of them were the job.
Closing note
The strange thing about this skill is that it cannot really be taught, only permitted. Every designer I have ever worked with already knew how to do this kind of work instinctively. They had simply been slowly trained out of it, one process artefact at a time, by an industry that confused looking organised with being good, that confused rigour with care, and that has now, most recently, confused having an AI write the work with having done the work.
This file is just permission. Print it out and pin it somewhere you can see it. Invoke it whenever you need to.
Do not, under any circumstances, turn this into a framework.
And if you really must, then please, at the very least, do not name it after a shape.