If you have installed a writing skill and found the output still does not sound like you, the skill is probably working exactly as designed. It just was not designed to do what you wanted.
Subtraction is not the same as voice
There is a whole genre of free Claude skills for writing, and it is dominated by one shape of tool. You give it text, it finds the phrases that read as machine-written, and it takes them out. The canonical one has over 45,000 stars and has been translated into at least seven languages.
These are genuinely useful and we ship one ourselves. But look at what the operation is. It compares your draft against a general standard of what AI writing sounds like, and removes the overlap. Nothing in that process has any information about how you write.
| Subtractive | Additive | |
|---|---|---|
| What it does | Removes phrasing that reads as machine-written | Reproduces the way one specific person writes |
| What it compares against | A general standard of AI tells | That person's actual published writing |
| What you get | Prose that reads as human and anonymous | Prose that reads as yours |
| How common | Dozens, one with over 45,000 stars | A handful, the largest at 264 stars |
‼️ The most popular LinkedIn humanizer skill is explicit about this, to its credit. It says it removes tells and only optionally builds a voice profile behind a flag, and it states plainly that it does not attempt to make text pass any AI detector. That is honest engineering. It is also not what most people installing it believe they are getting.
So the honest version of the gap is not that voice skills do not exist. It is that the ones that exist mostly subtract, and the ones that learn your voice have a tiny fraction of the users. If you searched for a writing skill and installed the top result, you almost certainly installed a subtractive one.
Where the additive ones fall short too, ours included
The skills that do try to model a voice split again, and this is the part nobody writes about.
Some ask you to paste in samples and derive a style profile from them. Those are doing the right thing in principle, and they are the small ones: the four we found sit at 264, 40, 18 and 9 stars. Others, and this includes every one of the skills we publish, are hand-authored. A person sat down and wrote instructions describing good writing, and those instructions are the same for every reader.
‼️ That is worth saying plainly about our own work. A hand-authored style skill is a style guide in a folder. Ours are careful, they are specific about structure and rhythm and what to avoid, and they will improve most people's drafts. What they cannot do is know how you write, because nothing in the file has ever seen anything you wrote.
The largest free marketing collection makes the same trade openly. It has nearly 49,000 stars and fifty skills, including copywriting, copy editing and social. Its skills read a brand voice file from your project and use whatever is in it. You supply the voice. The skill never builds one. That is a reasonable design and it puts the hard part back on you.
Which is the real answer to the title. A file cannot learn your voice, because a file does not have your posts. Getting from a style guide to something that sounds like a specific person needs evidence, and evidence means what you have actually published and which of it worked. That is the difference between a skill and a product, and it is why we ship both rather than pretending the files are enough.
A skill cannot post anything, and the reason is not a permission
Quick answer
No Claude skill can publish to LinkedIn or Twitter. On the API surface the sandbox has no network access at all. But even in Claude Code, where a skill has the same network access as any program on your machine, there is no credential, no session and no authentication mechanism anywhere in the skill format. The missing network is a per-surface detail. The missing identity is the design.
This is the most common confusion in the topic and it is worth getting exactly right, because the sloppy version is wrong in both directions.
- On the Claude API, skills run in a sandbox with, in Anthropic's words, no network access and no runtime package installation.
- On claude.ai, network access varies with a setting. The default permits package registries only, and a reader would have to deliberately open egress to a specific domain.
- In Claude Code, a skill has full network access, the same as any other program on your computer. A script bundled in the folder could in principle reach anything you could.
- And it still cannot post, because there is no place in the format to put a credential, no auth negotiation, and Anthropic explicitly tells authors not to hardcode secrets and to use a connector for external services instead.
The distinction that resolves it: a connector is the wire, and a skill is the instruction sheet taped next to it. Unplug the wire and the instruction sheet is still a perfectly good instruction sheet. It just does not carry current. If you want Claude to actually publish, you need a connector, which we covered in can Claude post to LinkedIn.
Anthropic's own recommendation for anyone building in this space is to do both, in that order: a remote connector with proper authentication first, then a plugin of skills that helps people use it well. It notes that most partners ship both.
The one mechanical fact that explains everything else
When a skill matches what you asked for, Claude opens the file and reads it, using a shell command. That is the whole mechanism. Only the name and description are loaded up front, at roughly a hundred tokens each, and the body arrives only when triggered.
Every confusing thing about skills follows from that one sentence.
- Why code execution must be switched on even for a skill that is pure prose. Without a filesystem and a shell, there is nothing to read the file with. The setting is not there so your skill can run Python. It is there so Claude can open your markdown.
- Why skills do not sync between surfaces. They are files in a location, and the locations are different.
- Why a skill has no permissions of its own. It borrows whatever access Claude already has. That is also why Anthropic treats a malicious skill as a serious risk rather than a nuisance.
- Why you can install a lot of them cheaply. Until one is triggered it costs you a name and a description.
Where the file actually goes
Since this is the question people arrive with, here it is in one table. Read the date on this: paths change, and several guides still publish ones that have moved.
| Surface | Where the skill goes |
|---|---|
| Claude Code, just you | A skills folder inside your home .claude directory, one folder per skill, each with a SKILL.md at its root |
| Claude Code, one project | The same shape inside the project's .claude directory |
| Claude Code, from a plugin | A skills folder inside the plugin, invoked with the plugin name and skill name together |
| claude.ai and Claude Desktop | Not on disk at all. A ZIP upload under Customize, then Skills. The skill folder must be at the root of the ZIP, not nested inside another folder |
| Cowork | The same account-level skills as claude.ai |
| Codex and Cursor | Their own agents and skills directories, and Cursor also reads the Claude and Codex locations for compatibility |
Two traps in that upload flow are worth knowing before you hit them. Extra frontmatter fields are a hard error rather than an ignored value, so a skill written with Claude Code specific fields in its header will fail to upload rather than degrade gracefully. And the words claude and anthropic are rejected in a skill's name by Anthropic's validator, though the open specification permits them.
There is also a live contradiction in Anthropic's own documentation that you should test rather than trust. The claude.ai help page gives the description field a maximum of 200 characters. The platform documentation gives the same field 1,024. Both were live on 9 September 2026. If you are writing a skill for upload, the safe move is to stay under 200 until you have proved otherwise with a real upload.
Star counts are actively misleading here
If you are picking skills by popularity, one thing will waste your afternoon. The two most-starred skill collections on GitHub contain no skills. One advertises more than a thousand agent skills and has over 33,000 stars; the other has over 15,000. Both are lists of links to other repositories. Clone either expecting files to drop into your skills folder and you get a README.
The directories are not much better as a signal. One claims to index over two million skills, which is a count of folders a crawler matched rather than things worth installing. Another lists tens of thousands of skills alongside thousands of connectors on the same ranked surface, which is precisely how a reader ends up installing a server when they meant to install a file.
There is no app store for this. Anthropic's own directory is partner-shaped with no published submission route for skills, and the routes that are open to anyone are a plain repository or a plugin marketplace, which by Anthropic's own documentation has no approval or review process at all.
Which means you should read one before you install it
A skill is instructions that Claude will follow. Installing one from a stranger is closer to running a stranger's shell script than to reading a stranger's blog post, and Anthropic says so directly, advising people to treat it like installing software and to use skills only from sources they trust.
The one large study we could find scanned 3,984 skills from two community registries in February 2026. Its findings, stated the way its own body states them rather than the way its headline does: about 37 percent carried at least one security issue of any severity, 13 percent carried at least one rated critical, and 76 were confirmed malicious after human review. Those are three different numbers measuring three different things, and most write-ups of that study collapse them into one.
The proportionate reading is that this is a software supply chain now, and it has the problems supply chains have. A writing skill is a low-risk category, because prose instructions cannot do much on their own. A skill that bundles scripts, fetches from a URL, or asks for a credential is a different proposition.
What to do with all this
- Work out whether you want subtraction or voice. If your drafts read like a press release, a humanizer helps immediately. If they read fine but not like you, no humanizer will fix that.
- Open the SKILL.md before installing. It is markdown. You can read the whole thing in two minutes and you will learn more than any comparison table tells you.
- Ignore stars. Check whether the repository actually contains SKILL.md files, and check the last commit date rather than the push date.
- Keep your header to name and description if you want the skill to work anywhere. Anything more is a Claude Code skill, not a portable one.
- If you want Claude to publish rather than draft, you need a connector, and that is a different set of trade-offs entirely.
Where we stand
We publish twenty-two free skills, split across a LinkedIn set and a Twitter set. They declare only a name and a description, which is the portable minimum, so they load on any surface that reads the format rather than only in Claude Code. Several are about voice and one is a humanizer.
They are also hand-authored, which is the limitation this whole article is about. They encode what we think good writing looks like on each platform. They do not know your voice, because a file cannot. What closes that gap is evidence: your actual posts, and which of them worked. That lives in the product and in the MCP connector rather than in a markdown file, and we would rather explain the difference than blur it.
If you only ever use the free files and never touch the product, that is a completely reasonable outcome and the files are genuinely ours to give. Just know what they are.
For the connector side of this, see which LinkedIn MCP servers stop working after 60 days. For what LinkedIn will tell you about how your posts performed, which is the evidence half of the voice problem, see does LinkedIn have an analytics API.